Hi folks, I’ve created a pull request for the website change:
https://github.com/apache/zookeeper/pull/1834 Once the website is updated, I’ll make the announcement for 3.5 EoL. Thanks, Andor > On 2022. Feb 17., at 16:54, Szalay-Bekő Máté <szalay.beko.m...@gmail.com> > wrote: > > Thanks for the clarification, I like the plan! > >> having 2 active versions (stable and current) and when a new minor > version is announced, the least recent will get another 6 months of support > > What does this mean exactly? Just to be on the same page, this is what you > propose if we release 3.8.0 until let's say end of February 2022? > - 3.5 EoL 1st of June 2022 > - 3.6 EoL 1st of Sept 2022 (~6 months after 3.8.0 release) > - 3.7 will become "stable" > - 3.8 will become "current" > > Did anyone in the community test the latest 3.7 (which is still 3.7.0) with > large clusters in production? Are we confident saying 3.7 is stable? > (on the other hand, if we don't do the announcement, most likely people > won't start to migrate to 3.7) > > Mate > > On Wed, Feb 16, 2022 at 1:33 PM Enrico Olivelli <eolive...@gmail.com> wrote: > >> Andor, >> >> Il Mer 16 Feb 2022, 12:47 Andor Molnar <an...@apache.org> ha scritto: >> >>> Okay, I agree that keeping 2 active versions rather than tying ourselves >>> to some fixed deadlines makes more sense for ZooKeeper. Let’s go with >> this >>> approach then if there’s no other objections: >>> >>> 1) Add this information to the Releases web page: I’ll describe that >>> ZooKeeper is having 2 active versions (stable and current) and when a new >>> minor version is announced, the least recent will get another 6 months of >>> support (security and bugfixes), but after that it will become EoL. That >>> means no further releases are expected from the community and users >> should >>> follow the supported upgrade path. I’ll send this out for review soon. >>> >> >> +1 >> >> >>> 2) Announce 3.5 EoL 1st of June 2022. (sorry Enrico, the end of the long >>> discussion is essentially what you originally proposed) >>> >> >> +1 >> Thanks >> >> >> Enrico >> >> >> >>> Please let me know if you have concerns with this path. >>> >>> Andor >>> >>> >>> >>>> On 2022. Feb 14., at 17:07, Patrick Hunt <ph...@apache.org> wrote: >>>> >>>> "Define what EOL means" - whatever we do let's make sure it gets onto >> the >>>> "releases" page so that folks have official information they can >>> reference >>>> from the project. >>>> >>>> I like having a max of 2 versions. Stable and current. I agree that due >>> to >>>> our lack of communication/policy so far we should ensure that people >> have >>>> opportunity to move/support on the release versions (3.x minors) we >>> current >>>> support. >>>> >>>> I like the idea of tying old releases to new ones. I don't think tying >>>> ourselves to a specific, long term is good though. It definitely >> reduces >>>> flexibility. Same with saying that new minors are going to be released >>>> every Y time. Can't we just say that a stable release will be supported >>> for >>>> a minimum of 6 months (other timeframe?) after moving the stable >>> indicator >>>> from 3.x to 3.x+1. We then have the flexibility to keep it around >> longer >>> if >>>> there is a reason why folks want to stick for a longer time (eg major >>>> changes in the more recent versions).... >>>> >>>> Patrick >>>> >>>> On Fri, Feb 11, 2022 at 8:08 AM Christopher <ctubb...@apache.org> >> wrote: >>>> >>>>> Regarding the suggestion: "Maybe we can also communicate that we’re >>> going >>>>> to officially EoL the least recent ZK version every 2 years." If you >>>>> release new versions less frequently than that, the number of >>> maintenance >>>>> versions will go to 0 (though, in practice, you wouldn't EOL your >>> current >>>>> release). If you release more frequently, you'll be stuck maintaining >> an >>>>> increasing number of versions. >>>>> >>>>> To keep the maintenance burden relatively consistent, I suggest tying >>> your >>>>> EOL schedule to your release schedule, so when you release a new >>> version, >>>>> you drop the oldest one. If you release every 2 years, then it works >> out >>>>> the same. But if you release more or less often, your maintenance >> burden >>>>> stays consistent. >>>>> >>>>> I would start by deciding the minimum number of concurrent versions >> you >>>>> want to maintain. I suggest no more than 2, but ZK currently has 3, >> and >>> is >>>>> about to be 4 soon. If you're not marking specific versions as >> long-term >>>>> stable, then the default would be to assume you're maintaining the >> most >>>>> recent versions. >>>>> >>>>> Then, consider churn. If you release frequently, you may want to set a >>>>> minimum age for maintenance, so users aren't forced to upgrade too >>> often. >>>>> So, if you start with 2 concurrent versions and you have a few >> versions >>>>> released rapidly, you may temporarily need to support up to 3 or 4 >>> releases >>>>> until the oldest ones reach the minimum age, like 2 years for example, >>> and >>>>> are able to be EOL'd. >>>>> >>>>> Then, consider upgrade overlap. When you release, you could EOL the >>> oldest >>>>> version right away. But, it might be nicer to wait a few months, or >>> maybe >>>>> up to a year, before the oldest one is EOL'd. >>>>> >>>>> I previously mentioned Accumulo's "LTM" strategy. These are the core >>>>> considerations we had in mind. So, for example, we support a minimum >> of >>> 1 >>>>> LTM version, with a 1 year overlap. We don't release frequently enough >>> for >>>>> the minimum age to be of concern. However, we did want to allow for >>>>> intermediate feature preview releases that are immediately EOL as soon >>> as a >>>>> newer version is available. So, at any given time, we are maintaining >>>>> between 1 and 2 LTM releases, and no more than 1 non-LTM release. We >>> also >>>>> use this to provide users with information about supported upgrade >>> paths so >>>>> users can upgrade from LTM to LTM, skipping over non-LTM releases, or >>> they >>>>> can stay on the latest (whether or not it is LTM). >>>>> >>>>> For ZooKeeper, I would suggest: >>>>> * maintain at least 2 versions (currently 3.6 and 3.7) >>>>> * maintain for at least 3 years before EOL >>>>> >>>>> >>>>> On Fri, Feb 11, 2022 at 9:10 AM Andor Molnar <an...@apache.org> >> wrote: >>>>> >>>>>> Thanks for the pointers. It was good to help refreshing my memory. >>>>>> >>>>>> We definitely missed the communication when stable and current links >>> were >>>>>> flipped from one version to another. Things will get more interesting >>>>> when >>>>>> Enrico finally releases 3.8.0. We’ll end up having 3 different >> “stable" >>>>>> branches and 3.8 will become the “current”. >>>>>> >>>>>> What can we do with this? >>>>>> >>>>>> Announcing 3.5 EoL >>>>>> ~~~~~~~~~~~~~~~~~~ >>>>>> >>>>>> This should have been done before flipping the stable pointer, but >>>>> anyway, >>>>>> here’re the points that we considered when doing the same for 3.4: >>>>>> - Discussion happened in March/April 2020, EoL was announced for 1st >> of >>>>>> June, 2020 (3 months ahead). >>>>>> >>>>>> - Define what EOL means - This is already discussed, text can be >>>>>> copy-pasted from 3.4 EoL message, >>>>>> >>>>>> - Provide guidelines for upgrading paths, >>>>>> >>>>>> - State interoperability guarantees >>>>>> - Previous version of ZooKeeper client is able to connect to server >>> as >>>>>> long >>>>>> as there’s no new feature enforced on server side, >>>>>> - Previous version of ZooKeeper server is able to accept >> connections >>>>>> from >>>>>> clients as long as they don’t want to use new features. >>>>>> >>>>>> - Curator already supports later versions - Is it true for 3.6, 3.7? >>>>>> >>>>>> It’s February now, so if we nail down the above points, I don’t see >> any >>>>>> objections against announcing 3.5 EoL for 1st of June, 2022 (2 years >>>>> after >>>>>> 3.4 EoL, providing 4 months to upgrade). Maybe we can also >> communicate >>>>> that >>>>>> we’re going to officially EoL the least recent ZK version every 2 >>> years. >>>>>> >>>>>> Andor >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On 2022. Feb 9., at 20:28, Patrick Hunt <ph...@apache.org> wrote: >>>>>>> >>>>>>> On Wed, Feb 9, 2022 at 3:07 AM Andor Molnar <an...@apache.org> >> wrote: >>>>>>> >>>>>>>> Hi Pat, >>>>>>>> >>>>>>>> Yeah, I asked for a more specific suggestion from you. If we avoid >>>>> using >>>>>>>> the LTS in ZooKeeper releases and stay with the stable/latest >> labels, >>>>>> how >>>>>>>> would you label the current maintained versions? >>>>>>>> >>>>>>> >>>>>>> Ah, ok. No worries Andor, I misunderstood. My 0.02: >>>>>>> >>>>>>> We have "stable" and "current" already identified. >>>>>>> https://dlcdn.apache.org/zookeeper/ >>>>>>> Stable was last updated in April of 2021. My recommendation is that >> we >>>>>>> should change the process to notify EOL prior to updating e.g. >>> "stable" >>>>>>> reference. Stable is our indication w/o using the LTS label. As long >>> as >>>>>> we >>>>>>> have a public policy & associated announcements, I think that's >> fine. >>>>>>> >>>>>>> I also bring your attention to this conversation thread from March >>> 2020 >>>>>> for >>>>>>> the previous EOL'd (3.4) release line: >>>>>>> https://markmail.org/message/b2pqcztlb2ixoyjp >>>>>>> Some good ideas in there from many folks, I think we settled on a >>>>>> timeframe >>>>>>> we felt comfortable with, at least at the time. Unfortunately we did >>>>> not >>>>>>> follow through with a plan for future releases. Perhaps we can do >> that >>>>>> now. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Patrick >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Enrico is about to release 3.8.0 soon, so we’ll end up having four >>>>>>>> versions in maintenance. What should we do with it to reduce the >>>>>>>> maintenance cost? >>>>>>>> >>>>>>>> Andor >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 2022. Feb 4., at 17:58, Patrick Hunt <ph...@apache.org> wrote: >>>>>>>>> >>>>>>>>> On Fri, Feb 4, 2022 at 8:19 AM Andor Molnar <an...@apache.org> >>>>> wrote: >>>>>>>>> >>>>>>>>>> More specifically? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Are you asking me? :-) "LTS" literally has a definition in >>>>> wikipedia: >>>>>>>>> https://en.wikipedia.org/wiki/Long-term_support >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Stable 3.5, 3.6, 3.7, 3.8 and EoL 3.5 at the end of the year (1st >>> of >>>>>>>> Jan, >>>>>>>>>> 2023)? >>>>>>>>>> >>>>>>>>>> Andor >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2022. Feb 1., at 16:41, Patrick Hunt <ph...@apache.org> >> wrote: >>>>>>>>>>> >>>>>>>>>>> "LTS" typically has meaning for folks beyond just what the words >>>>> say. >>>>>>>> JDK >>>>>>>>>>> LTS. Ubuntu LTS. etc... I think it would be less confusing to >> stay >>>>>> with >>>>>>>>>> the >>>>>>>>>>> stable/latest labels we have had in the past and plan ahead a >> bit >>>>> in >>>>>>>>>> terms >>>>>>>>>>> of giving notice when releases will be removed from support. >>>>>>>>>>> >>>>>>>>>>> Patrick >>>>>>>>>>> >>>>>>>>>>> On Tue, Feb 1, 2022 at 3:12 AM Andor Molnar <an...@apache.org> >>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Andrew, >>>>>>>>>>>> >>>>>>>>>>>> I think that wasn’t a general plan from the community at that >>>>> time, >>>>>>>> just >>>>>>>>>>>> my opinion based on how long 3.4 was the stable release of >>>>> ZooKeeper >>>>>>>> (4 >>>>>>>>>>>> years). Since then the release schedule has become much faster >>> and >>>>>> to >>>>>>>> be >>>>>>>>>>>> honest I’m not participating in it. >>>>>>>>>>>> >>>>>>>>>>>> As mentioned 3.6 and 3.7 releases are not much different. 3.6 >> is >>>>> the >>>>>>>>>>>> “Facebook” version which is well tested and contains lots of >>>>> patches >>>>>>>>>> that >>>>>>>>>>>> improves robustness. Both versions are good candidates for >>>>> upgrade, >>>>>> so >>>>>>>>>>>> announcing 3.5 EoL (at least half year from now) is not >>>>> necessarily >>>>>>>> bad. >>>>>>>>>>>> >>>>>>>>>>>> As an alternative, staying with the LT(S|M) / non-LT(S|M) >> terms, >>> I >>>>>>>> think >>>>>>>>>>>> the following could also be considered for the community: >>>>>>>>>>>> >>>>>>>>>>>> Now: >>>>>>>>>>>> >>>>>>>>>>>> master >>>>>>>>>>>> ---------- >>>>>>>>>>>> 3.7 >>>>>>>>>>>> 3.6 >>>>>>>>>>>> 3.5 LTS >>>>>>>>>>>> ---------- >>>>>>>>>>>> 3.4 EoL >>>>>>>>>>>> >>>>>>>>>>>> Can become: >>>>>>>>>>>> >>>>>>>>>>>> master >>>>>>>>>>>> ---------- >>>>>>>>>>>> 3.8 LTS >>>>>>>>>>>> 3.7 >>>>>>>>>>>> 3.5 LTS >>>>>>>>>>>> ---------- >>>>>>>>>>>> 3.6 EoL >>>>>>>>>>>> 3.4 EoL >>>>>>>>>>>> >>>>>>>>>>>> In order to keep the number of maintained branches low. >>>>>>>>>>>> >>>>>>>>>>>> What do you think? >>>>>>>>>>>> >>>>>>>>>>>> Andor >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 2022. Jan 31., at 19:41, Andrew Purtell < >> apurt...@apache.org >>>> >>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Just to be clear I meant 'you' as the ZooKeeper project as a >>>>> whole, >>>>>>>> but >>>>>>>>>>>>> maybe I have misunderstood this response: >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> https://issues.apache.org/jira/browse/HADOOP-17612?focusedCommentId=17311792&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17311792 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sun, Jan 30, 2022 at 10:29 AM Enrico Olivelli < >>>>>>>> eolive...@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Il Dom 30 Gen 2022, 17:51 Andrew Purtell < >>>>>> andrew.purt...@gmail.com> >>>>>>>>>> ha >>>>>>>>>>>>>> scritto: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Previously in various contexts - specifically, I am thinking >>>>> of a >>>>>>>>>>>> Hadoop >>>>>>>>>>>>>>> JIRA where we once had a conversation on this topic, but I >>>>>> believe >>>>>>>>>>>> there >>>>>>>>>>>>>>> have been others - you have declared 3.5 a long term stable >>>>> (LTS) >>>>>>>>>>>>>> release. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A sudden EOL of an LTS is jarring and makes future promise >> of >>>>> LTS >>>>>>>>>>>>>>> untrustworthy. What I would recommend for what it’s worth >> is a >>>>>>>>>>>> timetable >>>>>>>>>>>>>> to >>>>>>>>>>>>>>> EOL of 3.5 that is reasonably long, like one or two years, >>>>> should >>>>>>>> you >>>>>>>>>>>>>>> decide to EOL it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am sorry, >>>>>>>>>>>>>> I forgot about such conversation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can you share some pointers ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> No problem from my side as soon as there is someone who needs >>>>> 3.5 >>>>>>>> and >>>>>>>>>>>> that >>>>>>>>>>>>>> is willing to help. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Our codebase is pretty stable and we usually pay much >> attention >>>>>> to >>>>>>>>>>>>>> compatibility. So I am sure that 3.5 clients will be able to >>>>>> connect >>>>>>>>>> to >>>>>>>>>>>> new >>>>>>>>>>>>>> servers (and vice versa) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I opened up this discussion to see how much interest is in >> the >>>>>>>>>>>> community, >>>>>>>>>>>>>> so from your response I understand that there is such >> interest. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for answering >>>>>>>>>>>>>> >>>>>>>>>>>>>> Enrico >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Jan 30, 2022, at 5:00 AM, Enrico Olivelli < >>>>>> eolive...@gmail.com >>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> We are going to release 3.8.0. >>>>>>>>>>>>>>>> It is time to think about moving 3.5 to EOL. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Key points: >>>>>>>>>>>>>>>> - we already have a few other "active" branches, 3.6 and >> 3.7 >>>>>>>>>>>>>>>> - 3.5 still has "ant" files, and cherry picking libraries >>>>>> upgrade >>>>>>>> is >>>>>>>>>>>>>>>> awkward (you always have to create a separate patch) >>>>>>>>>>>>>>>> - moving to 3.6 is quite easy, so people should not be >> stuck >>>>> if >>>>>>>>>>>>>>>> requested to upgrade to 3.6 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thoughts ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Enrico >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Andrew >>>>>>>>>>>>> >>>>>>>>>>>>> Unrest, ignorance distilled, nihilistic imbeciles - >>>>>>>>>>>>> It's what we’ve earned >>>>>>>>>>>>> Welcome, apocalypse, what’s taken you so long? >>>>>>>>>>>>> Bring us the fitting end that we’ve been counting on >>>>>>>>>>>>> - A23, Welcome, Apocalypse >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>> >>> >>
