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