I did manually create it because I noticed the previous ones, I did not realize those were automatically created in the past. Deleting all of those sounds good to me.
On Wed, Apr 19, 2023 at 10:32 PM Christopher <ctubb...@apache.org> wrote: > > 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
