Done
On Thu, Apr 20, 2023 at 10:57 AM Keith Turner <ke...@deenlo.com> wrote: > > 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
