GitHub user parshimers created a discussion: Policy and guidance on upgrades and backwards-compatibility between versions
Hi folks, I couldn't find any previous discussions about this topic, so I figured I'd start one, since I think it is an important issue. Currently, as I understand it, there are no specific guarantees about compatibility between released versions of Texera. That means you can't really be sure you could perform any kind of upgrade (e.g. from 1.2.0 to 1.2.1) without having to completely recreate all your workflows, datasets, and user logins from scratch. That certainly seems like it would be an issue to anyone wishing to deploy a Texera instance, even as an informal internal staging environment, let alone an outward facing service. Clearly we can't maintain compatibility between all versions, but at least we can do it in certain circumstances. I think the versioning scheme and release practices kind of have an implicit intention behind them related to this. My proposal would be to enforce and advertise this practice: - Bugfix releases (x.x.n -> x.x.n+1) should be entirely backwards and forwards compatible. - Minor releases (x.n.x -> x.n+1.x) may require migration advice on upgrade, but should be backwards compatible. - Major releases (n.x.x -> n+1.x.x) may be entirely incompatible in either direction, and require significant manual work to migrate to. Entire features that existed in a previous version may not exist, or are changed in an incompatible way. We should have CI tests to enforce this if it is accepted. It is very easy to accidentally introduce a change which is backwards or forwards incompatible. Pretty much anything that serializes, especially to persistent storage, can cause it. What does everyone think? GitHub link: https://github.com/apache/texera/discussions/8570 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
