Il Mer 8 Apr 2020, 12:34 Andor Molnar <an...@apache.org> ha scritto: > Hi, > > I’ve finished my quick testing on compatibility and all combinations are > working fine in both ways: higher version clients are able to connect and > run basic commands on older servers and vica versa. > > Tested latest released versions of 3.4, 3.5 and 3.6 branches with all > possible combinations. >
Good. One day we will have automated testing of this stuff :) > If there’s no more concerns or thoughts to share from the community, I’ll > send the announcement this afternoon CEST. > +1 Enrico > Thanks, > Andor > > > > > > On 2020. Apr 4., at 23:09, Patrick Hunt <ph...@apache.org> wrote: > > > > 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 > >
