Andor,

Il Mer 16 Feb 2022, 12:47 Andor Molnar <an...@apache.org> ha scritto:

> Okay, I agree that keeping 2 active versions rather than tying ourselves
> to some fixed deadlines makes more sense for ZooKeeper. Let’s go with this
> approach then if there’s no other objections:
>
> 1) Add this information to the Releases web page: I’ll describe that
> ZooKeeper is having 2 active versions (stable and current) and when a new
> minor version is announced, the least recent will get another 6 months of
> support (security and bugfixes), but after that it will become EoL. That
> means no further releases are expected from the community and users should
> follow the supported upgrade path. I’ll send this out for review soon.
>

+1


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

+1
Thanks


Enrico



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

Reply via email to