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é >
