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