On Fri, Apr 3, 2020 at 12:57 PM Patrick Hunt <ph...@apache.org> wrote: > > On Thu, Apr 2, 2020 at 1:14 PM Christopher <ctubb...@apache.org> wrote: > > > On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt <ph...@apache.org> wrote: > > > > > > On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar <an...@apache.org> wrote: > > > > > > > Alright. Not sure how to coordinate this properly, let’s try to discuss > > > > these 3 points individually. > > > > > > > > 1) EOL is 1st of June, 2020 which means from this day forward 3.4 is > > ... > > > > - not supported by the community dev team, > > > > - not accepting patches, no future releases, no security fixes, > > > > - latest version is still accessible at download page for 1(?) year > > > > > > > > > > > Apache archival process is documented on this page: > > > https://www.apache.org/legal/release-policy.html#when-to-archive > > > we do get nudged on it every so often: e.g. > > > https://issues.apache.org/jira/browse/ZOOKEEPER-1752 > > > > The archival process is regarding removal of old versions from the > > mirroring system. It does not apply to "current" releases ("current" > > being defined as still linked from the project's download page). > > > > > The text is pretty unequivocal and not what you are saying. > > "downloads.apache.org should contain *the latest release in each branch > that is currently under development*. When development ceases on a version > branch, releases of that branch should be removed from the project's > download directory." > > Meaning it should go to archive only once the branch is no longer under > active development, not that it would be "removed". The semantics btw > archive and remove are different. I don't think we should ever truly > "remove" anything once we've officially released it. eg. you can still find > 3.3 on the archive site if you want it.
The portion you are quoting is from an FAQ, below the release policy, not the release policy itself. The actual policy doesn't address the archival *process*, only the requirement that releases be archived. The release policy is set by VP Legal, whereas the release and archival *processes* are managed by VP Infra. The FAQs have their shortcomings and could be improved (this isn't the first time these FAQs have caused confusion by seemingly conflicting with how INFRA operates the distribution channels). In order to be consistent with best practices for how the mirror system is intended to be used for release artifact distribution, I interpret "When development ceases" to refer to the entire development lifecycle, including release promotion via announcements and availability on the downloads page. Otherwise, you'd have to archive any "final release" of a branch immediately, and if you wanted to widely distribute the release by promoting it on the downloads page, you would have to link to the archives.... which is *BAD*. Projects should distribute releases via the mirroring system, not via the archives. Once they stop promoting the artifacts on their downloads page, the artifacts should be removed (archived) from SVN/dist.apache.org as the same time. If you're uncomfortable with interpreting "development" to include the release promotion period where they are linked on the downloads page, you could instead just choose to not "cease" development until you are ready to remove it from the downloads page. You could slow development down to the point where maybe you might still release critical security fixes, for example, but really nothing else. Development is still "active" and hasn't "ceased". But, what you should not do, is continue promoting the artifact on the downloads page with a link to the archives. If somebody from INFRA wants to contradict me on this... I'm happy to be corrected with more accurate information... but I'm 99% confident they don't want releases being promoted that cause users to pull more heavily on the archives servers, as that would be a costly drain on Foundation resources. All that said, the last 3.4 release has been promoted on the downloads page for over a year now, which is probably long enough for a final release, so it's probably easiest to just go ahead and remove it from your downloads page (and from the mirrors, of course) sooner, rather than wait until later.
