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