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. On Thu, Jan 7, 2016 at 12:30 PM Wei ZHOU <ustcweiz...@gmail.com> wrote: > 2016-01-07 15:24 GMT+01:00 Rene Moser <m...@renemoser.net>: > > > Hi Remi > > > > On 01/07/2016 02:28 PM, Remi Bergsma wrote: > > > I simply don’t understand why you need lots and lots of minor versions. > > I do understand you need a stable cloud, and that’s exactly what we’re > > achieving here. > > > > > > We changed our way of working from 4.6 on. Before that, it took _a > long_ > > time to release new versions (be it major, minor or patch). Releases were > > not high quality so people waited for .1 or .2 to be released. When you > did > > eventually upgrade, you’d hit major trouble. It was simply not OK. And > many > > minor releases don’t help here. The root cause of the trouble is that the > > whole idea of branching off a new version and have a QA team make it > stable > > (while the rest continues on master) doesn’t make sense (any more). > That’s > > why in the summer of 2015 we decided to stabilise master instead and > > release from that. [1] One final time it took a great effort to make a > > branch stable. > > > > > > We released 4.6 in Nov 2015 > > > We released 4.7 in Dec 2015 > > > We will release 4.8 in Jan 2016 (unless people think I should stop > doing > > this) > > > > > > In between, we submitted patch releases to quickly address bugs (4.6.1, > > 4.6.2 etc). > > > > What about 4.5? 4.4? Is 4.6 still getting 4.6.3? Users don't see that. > > > > > You know what? It’s easy to do these upgrades. Much much easier than > > before. The change is small, the procedure is quick. > > > > We are not yet on 4.6, so we have downtime by upgrading the routers, we > > have approx 120 VR, which take about ~ 5-10 minutes of downtime each. > > > > > If you use isolated network with redundant VR, you can try to apply the PR > https://github.com/apache/cloudstack/pull/1198 > then restart networks with cleanup, the new VRs will run with new systemvm > template, downtime is acceptable (1s-3s). > > We used isolated network with single VR before, we had another patch to > modify the networks to be with RVR, and the existing VR as master VR. > However, the patch is not applicable for 4.6 and later. > > > > We are not agile in upgrading, we have freeze times and plan our > > releases and test each release intensively (it saved our asses in the > > past). > > > > Every bigger software project in the world has agreed that providing > > minor releases is good practice: > > > > - New features --> Major release > > - Fixes --> Minor release > > > > The problem with new features are potentially new bugs (by nature): > > > > Now you are basically saying: > > > > - New features and fixes --> Major release only > > > > By definition, you will end up it a more unstable software because you > > will only get fixes in cost of new features and potentially new bugs. I > > don't call this stable. > > > > I do not see any benefit of the current release rush. > > > > René > > >
