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. If there’s no more concerns or thoughts to share from the community, I’ll send the announcement this afternoon CEST. 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
