I totally agree Marcus, with one small addition. In our present scheme we can mark any 4.x as LTS if we maintain the discipline of fixing any bug on the oldest version known to contain the bug and merge the fix forward. some LIMITATION OF WARRANTY (tm) apply of course; if a fix requires some kind of database change...
Basically our present release scheme was designed to address the concerns you are describing. On Thu, Jan 7, 2016 at 10:30 PM, Marcus <shadow...@gmail.com> wrote: > A few things to note: > > 1. I repeated this until I felt bad about harping on it, but we were seeing > new functionality slip into minors all the time. The idea that 4.4.x -> > 4.4.y upgrade was safer than 4.4.x -> 4.5.0 (just made up versions as an > example) is unfortunately wrong. > > 2. I agree that large production environments will probably only want to > upgrade their cloud once every few months, at the most. Probably less, due > to internal testing and qualification for each chosen major. I understand > the mindset someone might have when they're told that they need to jump six > major releases and pull in dozens of new features to fix one or two bugs > they have come across in their otherwise stable cloud. Suddenly they're > thinking they need to do far more integration testing with their internal > CloudStack consumers and their infrastructure. Even if the releases are > more stable, any major release is going to be treated as an unknown and > require rigorous qualifications. Due to #1, this point is largely moot, > but if we were doing proper bugfix releases, or chose to go that direction, > it might be something important to think about. > > In the end, it probably doesn't matter much either way for routine > maintenance. If you were upgrading once every 6-12 months to keep up with > the previous major cycle, you can still upgrade at that pace and the delta > in changes between your chosen minors will be roughly what it was before, > even if the minors aren't contiguous numbers. The place this breaks down is > that while you can pick a release from any month and decide to use that as > your next 6-12 month version, there are far fewer people running your > version or focusing on it for bugfixes; you've been left behind once you've > settled on running that version. So you either have to get with the program > and figure out how to do rapid releases in your environment that is averse > to change and full of red tape, or start maintaining your own release > builds. That's kind of a crappy choice that we're putting on our less agile > users. > > To that end, I like the idea of the LTS, simply tagging majors as the > preferred version for people who require a slower upgrade. This would focus > those users into certain versions and improve maintenance on them. It could > even just be unofficial, a version that CloudStack users agree on. From a > versioning perspective this doesn't sound a whole lot different from the > old scheme where 4.4 and 4.5 were essentially an LTS, but it is still > better because we've improved the release process. Of course, we still have > to reign in the changes to these LTS versions and stop allowing new > features to creep in simply because customers who are on that LTS need the > feature. > -- Daan
