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.
