I don't know about other Apache projects but the Go Programming Language uses a slower release cadence, two releases a year. Only the last two releases are maintained with backports, except for significant security issues, which are backported as far back as possible.
Further they divide each release period into clear 3 month "commit" and " fix" periods, with the main tree only open to new features in the commit phase with the fix phase largely frozen outside of discovered issues. Beam isn't entirely the same thing as a Programming Language, and certainly hasn't had such a rigorous commitment to forward compatibility as Go has. There's been a very strong expectation that Go programs must continue to compile, and function as expected through new versions of Go, and it's standard libraries (and to a lesser extent, arbitrary Go packages). But these tenets allow the Go maintainers and contributors to avoid LTS as a concept to worry about. The way I see it, it's not necessarily the number of releases that's the problem exactly, but the overall stability of the system. More frequent releases "feels" less stable than fewer, even if most of them are compatible ona code level. This will vary on the way language ecosystems handle dependencies though. Beam is also multi language, which adjusts concerns. How does GRPC handle that? Or protos? (I'm sure there are other examples we can pull from...) On Thu, Apr 8, 2021, 9:31 AM Kenneth Knowles <k...@apache.org> wrote: > The other obvious question, which I often ask and very rarely research: > what do other similar projects do? Does anyone know? > > On Thu, Apr 8, 2021 at 9:30 AM Kenneth Knowles <k...@apache.org> wrote: > >> I want to send a short summary of my views. There is a >> tension/contradiction that I think is OK: >> >> - An LTS series becomes more valuable when more stakeholders care for >> it. For those who don't care about LTS, the main thing would be to >> highlight major issues that are worth backporting. So having it part of how >> we think about things is helpful, even for the people who are not using it >> or supporting users of it. And cherrypicks are very easy to open. So I >> support building consensus around this. >> >> - Anyone can volunteer and perform a point release for any past branch. >> IMO if a stakeholder proposed to do the work, we (the Beam community) >> should welcome it. Certainly we have no ability to make anyone else do the >> point releases or directly fund any work. So I support welcoming such a >> contribution but not making unfunded commitments. >> >> In practice: I think if CompanyX has a customer who wants LTS support, >> CompanyX commits to the customer that they will perform LTS support and >> CompanyX can be sure that the Beam community welcomes such a contribution, >> and their customer can easily confirm Beam community's public position on >> it. >> >> Kenn >> >> On Thu, Apr 8, 2021 at 1:05 AM Jan Lukavský <je...@seznam.cz> wrote: >> >>> Understand that, my point was just that we cannot care about API changes >>> only. What an LTS has to maintain is binary compatibility of state or >>> have any kind of upgrade process without the running Pipeline being >>> terminated and completely replaced with another one. Bootstrapping the >>> state is what is - from my point of view - the most expensive part of >>> upgrade with state-incompatibility. If an update to LTS breaks the state >>> compatibility, then upgrading to the new (bugfixed) LTS version seems to >>> be (about) the same pain as upgrading to the newest version of Beam. >>> That is what somewhat breaks the "LTS" expectations users might have. >>> But yes, fixes which break state might not be that frequent, but are >>> possible, that's for sure. In that case, we essentially could not >>> release a fix, even if it was critical security fix. My question was >>> then if these concerns will be somehow part of the proposed LTS support >>> process. >>> >>> Jan >>> >>> On 4/7/21 4:23 PM, Elliotte Rusty Harold wrote: >>> > On Tue, Apr 6, 2021 at 9:43 PM Jan Lukavský <je...@seznam.cz> wrote: >>> >> Hi, >>> >> do we know what is the reason users stay on an older version of Beam? >>> My guess would be that it is not related to API changes, but more likely to >>> state incompatibility. Maybe if we could figure out a way which would >>> enable a smooth migration of state (and timers) between Beam versions, that >>> might help? The migration would probably have to be runner-dependent, but >>> Beam might offer some tooling to make this easier. One example would be >>> coder evolution, where we currently do not have the option of "reading old >>> way, writing new way" with some "coder-version-registry". I suppose there >>> might have been a discussion about this in the past, does anyone know of >>> any conclusion? >>> >> >>> > Different customers have different requirements. The projects and >>> > teams I'm talking to simply don't want to invest engineering time in >>> > migrating as often as they have to now. They want to be able to ship a >>> > working product and not worry about it for a year or more. They >>> > recognize the possibility of unforeseen bugs and security issues that >>> > might require an update. However they'd like that update to be minimal >>> > and not require them to update their own code. Nor do they want to run >>> > the risk of performance regressions and newly introduced bugs and >>> > security issues. >>> > >>> >>
