I’m debating between tracking the latest/stable channel verses a specific LTS channel to maximize stability in a production environment. The concern I have about using an LTS channel, e.g. 5.0/stable, is that bugfixes that I end up needing may not get backported to the LTS channel. is there a policy or guidelines for which types of bugfixes will get backported? Or, can users open an issue on GitHub if a particular issue is affecting them and that could prompt considering a bugfix for backporting?
Related to this, I have some systems on latest/stable now. I know that in general downgrading is not supported, but is it supported to downgrade to the latest LTS, e.g. 5.0/stable? Or am I stuck waiting to switch to the LTS track until the next LTS (6.0) comes out?
Thanks for the clarification. Are schema changes never backported to an LTS release, or can they be in certain circumstances where it makes sense (e.g. high-impact bug that requires a minor schema change as part of the fix)?
I suppose never say “never”, but generally we do not want to prevent downgrade support in LTS.
So the bar for making a schema change in an LTS is pretty high.
There’s only a very small time window where schema changes can be backported and we’ve on occasion done it. But this tends to be immediately after an LTS version has been released and prior to any new feature landing in the development branch.
As soon as we need to add a DB table or do some schema changes for a new feature in the development branch, we are no longer able to backport any schema change to LTS releases.
That’s because our schema is versioned as an ever increasing integer. We need schema 33 to be the same everywhere or upgrades will fail quite disastrously.
It’s actually exceptionally rare for a DB schema change to have to be backported.
That’s also because DB data cleanup can be achieved through a separate mechanism we have, patches. Those patches unlike the schema changes can be pretty easily backported.