I noticed with 2.0.0, a new release at https://github.com/apache/fluo/releases (I think Keith manually created that as part of the 2.0.0 post-vote release steps? Perhaps he can confirm.)
In the past, all tags automatically got a "release" entry on GitHub. However, that is no longer the case. GitHub has now separated out the idea of a "release" from a "tag" enough that these aren't automatically created anymore, and we don't need to worry about updating them with release names and release notes. This feature in GitHub is primarily used as a way to make artifacts available for download, along with release notes. However, in ASF land, we have our website and the ASF-provided CDN for that and do not need this feature. I believe GitHub actually made that change to stop automatically creating faux "releases" for every tag as a result of pressure from the ASF, because these faux "releases" were being mistaken as official ASF releases, when they weren't. I can't remember the specific mailing list where this was discussed, but maybe one from LEGAL or COMDEV. To make matters worse, the content of these "releases" are not actually the same as the official source artifact releases from the ASF, that the PMC voted on, at all. They are merely GitHub UI magic to download a copy of the git source tree for a specified tag. The tag contents can, and often do, differ slightly from the actual official releases, and they also don't match our published checksums for releases and are not accompanied by the required GPG detached signatures. The downloads these link to can even change over time, if GitHub changes the way the file is generated from the repo (using a different timestamp, or different compression options). In order to reduce confusion and to avoid misrepresenting these as ASF releases when they are not, we should not be using this GitHub feature at all, and all these "releases", which are not actually ASF releases at all, should be deleted. This will not delete the tag, though. The tags will remain... and users can also append .zip or .tar.gz to a commit hash URL on GitHub to download a copy of the repo contents at that commit, without us using this, if they want to. For comparison, note that Apache Accumulo does not have any GitHub "releases" at https://github.com/apache/accumulo/releases, in spite of having many tags at https://github.com/apache/accumulo/tags Similarly, long-running projects like Hadoop and HTTPD do not do this either (https://github.com/apache/hadoop/releases, https://github.com/apache/httpd/releases). I did see that Maven does do this (https://github.com/apache/maven/releases), and I'm not sure their reasons, but for the technical/release policy/user experience reasons above, I think it's a really bad idea. If creating these "releases" are documented anywhere in our developer docs, we should update that documentation to correct that. Christopher
