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. -- Elliotte Rusty Harold elh...@ibiblio.org
