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 > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>> > >>> > >> > >
