On Fri, Apr 3, 2020 at 10:59 PM Christopher <ctubb...@apache.org> wrote:
> 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. > For 3.4 example specifically I don't see how it could be considered "in development" if we state that it's EOL as detailed by Andor above. That seems to meet the criteria as I understand it. I agree that removing it from the downloads page would be reasonable and consistent with that intent. Patrick
