Moving 3.5 to EOL

[Enrico Olivelli <eo...@gmail.com>]

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

Re: Moving 3.5 to EOL

[Christopher <ct...@apache.org>]

Apache Accumulo has gone through some similar discussions over the years.
What we have come up with is
https://accumulo.apache.org/contributor/versioning.html

(We avoided "LTS", because we don't provide "support" in the commercial
sense, instead using the term "LTM" for long-term maintenance to indicate
our intent to maintain with patches, but it's essentially the same kind of
thing)

Basically, we:

* define our API (https://accumulo.apache.org/api/) and use SemVer as much
as possible
* apply patches to at least 1, and at most 2, LTM releases at a time
* EOL the previous LTM release a year after the next one is released, to
give an entire year for people to transition while still receiving patches
* non-LTM releases are effectively EOL immediately, but can be used as
stepping stones to the next LTM release; it's not that they won't receive
patches at all, but that patches will be rolled into the current
development for the next release, rather than backported to that version

This helps a lot with reducing the developer workload to maintain multiple
branches, communicates our intent to patch, provides predictable update
paths, and gives users the choice to hop from one LTM release to the next
or to follow the non-LTM releases to adopt new features more quickly.

If ZK 3.5 is considered an "LTS" release, and if ZK devs wanted to do
something similar, I would recommend maybe marking 3.7 as the next "LTS"
release, and EOL'ing 3.5 either 1 year from now, or 1 year from 3.7.0's
release date (which is coming up in a few months). You could either make
3.6 an LTS release if you wanted to maintain 2-3 LTS releases at a time
instead of 1-2 like Accumulo does. Or you could EOL 3.6 when you EOL 3.5,
so you can focus on 3.7 as the current LTS.

There's lots of options to go with, but something along these lines,
documented, could be very useful for users and developers/contributors.

On Sun, Jan 30, 2022 at 1:29 PM Enrico Olivelli <eo...@gmail.com> wrote:

> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <an...@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 <eo...@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
> >
>

Re: Moving 3.5 to EOL

[Andrew Purtell <ap...@apache.org>]

That's what I was getting at with asking about phrasing like "long
supported" or LTS. The expectation is months or years longer than typical.
ZooKeeper code lines have typically been supported for really long times.
It is a strength of this project, in my opinion. Those of us who have been
around for a while, if we hear "LTS" from you, we think years and years...
Christopher from Accumulo had a good suggestion. Whatever you decide,
document it. Will help with communication. Probably best to avoid use of
the term "LTS" unless you plan on keeping that version around for several
years.

On Fri, Feb 4, 2022 at 8:59 AM 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 <ap...@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 <
> eolivelli@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <an...@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 <eolivelli@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
> > >>
> > >>
> >
> >
>


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

Re: Moving 3.5 to EOL

[Andor Molnar <an...@apache.org>]

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é <sz...@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 <eo...@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 <ct...@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 <
>> apurtell@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 <
>>>>>>>> eolivelli@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <
>>>>>> andrew.purtell@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 <
>>>>>> eolivelli@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
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> 
>> 

Re: Moving 3.5 to EOL

[Szalay-Bekő Máté <sz...@gmail.com>]

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 <eo...@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 <ct...@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 <
> apurtell@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 <
> > >>>>> eolivelli@gmail.com>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <
> > >>> andrew.purtell@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 <
> > >>> eolivelli@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
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> > >>
> >
> >
>

Re: Moving 3.5 to EOL

[Enrico Olivelli <eo...@gmail.com>]

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 <ct...@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 <apurtell@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 <
> >>>>> eolivelli@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <
> >>> andrew.purtell@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 <
> >>> eolivelli@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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
>
>

Re: Moving 3.5 to EOL

[Andor Molnar <an...@apache.org>]

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.

2) Announce 3.5 EoL 1st of June 2022. (sorry Enrico, the end of the long discussion is essentially what you originally proposed)

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 <ct...@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 <ap...@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 <
>>>>> eolivelli@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <
>>> andrew.purtell@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 <
>>> eolivelli@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
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
>> 

Re: Moving 3.5 to EOL

[Patrick Hunt <ph...@apache.org>]

"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 <ct...@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 <ap...@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 <
> > >> eolivelli@gmail.com>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <
> > andrew.purtell@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 <
> > eolivelli@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
> > >>>>>>
> > >>>>>>
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >
>

Re: Moving 3.5 to EOL

[Christopher <ct...@apache.org>]

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 <ap...@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 <
> >> eolivelli@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <
> andrew.purtell@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 <
> eolivelli@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
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>

Re: Moving 3.5 to EOL

[Andor Molnar <an...@apache.org>]

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 <ap...@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 <
>> eolivelli@gmail.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <an...@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 <eolivelli@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
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>> 

Re: Moving 3.5 to EOL

[Patrick Hunt <ph...@apache.org>]

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 <ap...@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 <
> eolivelli@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <an...@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 <eolivelli@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
> >>>>
> >>>>
> >>
> >>
>
>

Re: Moving 3.5 to EOL

[Andor Molnar <an...@apache.org>]

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?

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 <ap...@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 <eo...@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <an...@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 <eo...@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
>>>> 
>>>> 
>> 
>> 

Re: Moving 3.5 to EOL

[Patrick Hunt <ph...@apache.org>]

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 <ap...@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 <eo...@gmail.com>
> >>> wrote:
> >>>
> >>>> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <an...@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 <eo...@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
> >>
> >>
>
>

Re: Moving 3.5 to EOL

[Andor Molnar <an...@apache.org>]

More specifically?

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 <ap...@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 <eo...@gmail.com>
>>> wrote:
>>> 
>>>> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <an...@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 <eo...@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
>> 
>> 

Re: Moving 3.5 to EOL

[Patrick Hunt <ph...@apache.org>]

"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 <ap...@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 <eo...@gmail.com>
> > wrote:
> >
> >> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <an...@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 <eo...@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
>
>

Re: Moving 3.5 to EOL

[Andor Molnar <an...@apache.org>]

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 <ap...@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 <eo...@gmail.com>
> wrote:
> 
>> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <an...@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 <eo...@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

Re: Moving 3.5 to EOL

[Andrew Purtell <ap...@apache.org>]

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 <eo...@gmail.com>
wrote:

> Il Dom 30 Gen 2022, 17:51 Andrew Purtell <an...@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 <eo...@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

Re: Moving 3.5 to EOL

[Enrico Olivelli <eo...@gmail.com>]

Il Dom 30 Gen 2022, 17:51 Andrew Purtell <an...@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 <eo...@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
>

Re: Moving 3.5 to EOL

[Andrew Purtell <an...@gmail.com>]

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. 


> On Jan 30, 2022, at 5:00 AM, Enrico Olivelli <eo...@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