I have suggested before that if the team can at least maintain n-1 for 1 year with bug fixes only that would go along way. In this case the 7.2.x branch would be maintained until A) 1 year passes or B) v9 comes out making v7 n-2. bench
needs to be fixed to actually handle the switch that is mentioned in the upgrade function to stay on a particular version. git
supports this dual branch system today.
The release cycle also needs work. As to @Julian_Robbins comment. Way too often a release fixes or improves one thing but break one or more other things. There needs to be a process in place where releases are tested before being merged into master and let loose to the world.
I have gotten in the practice of every month updating by test instance. I restore the prod database there since they are both the same version and then update the code base and do some regression testing. Right now it is a bit ad hoc. I want to create an actual test plan, but have not had the time. However, even with my ad hoc testing I find strange behavior. I wait a few days and a few releases and then the issues do get fixed, often without a git issue being opened and often with hardly no mention in the notes.
I am pretty sure we all experience this. This conversation has lots of other examples on it.