Hi René, all, 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). You know what? It’s easy to do these upgrades. Much much easier than before. The change is small, the procedure is quick. I upgraded our production environment from 4.6.2 to 4.7.0 in under 10 minutes (a clustered setup). When 4.7.0 got released, for the first time ever, we knew 100% sure it included everything from 4.6 as it was built on top of it. No regression between 4.6 and 4.7. Actually there’s no need to use 4.6 any more, when 4.7 is out. It’s essentially the same, plus new features. So, yes, monthly releases can be done and the quality is better than before. Actually, I think we should go much faster. Whenever a PR is merged that fixes your issue, it should be possible to deploy it right away. It’s a change in mindset. Before this change, master was broken all the time. Now you can even run production from master. It just works (tm). Users should pick the latest version. If someone wants to maintain an older release, that can be done. I know Rohit maintains older versions for ShapeBlue customers and that makes sense. Until everyone gets used to an agile way of working this may still be needed. I just don’t work that way any more. To summarise, you want a stable cloud and I think since 4.6 we provide just that. Quick releases, fast delivery of new features and even faster delivery of bug fixes. There will always be bugs, so the faster we release, the smaller the diff and the easier the deploy and best of all: the sooner the bug is resolved in production. To be honest, I have the feeling not much people agree with me. So maybe I should stop doing this. I also see it in the number of people reviewing and testing. It’s simply disappointing. Anyway, let me know what you guys want. If people want to go back to the old way of working then that’s also fine with me. I just won’t be the Release Manager of it. Let me know! Regards, Remi [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up PS: At work we run multiple CloudStack powered clouds with hundreds of hypervisors so I think I know what I'm talking about. On 07/01/16 13:39, "Rene Moser" <m...@renemoser.net> wrote: >Hi > >I don't want to be the Grinch but this new release cycle feels not >matching users needs. Especially not my employers one. > >We are releasing major versions every month? Great! So we release a >minors every week/day!? No, we don't! :( Every couple of months actually. > >A release not getting minors is not a release! It is a dead horse. > >Questions: > >* Who will use 4.6? when 4.8 was released? >* Is 4.6 still maintained, is 4.5 maintained? is 4.4 maintained? >* Do we really think, clouds will be major upgraded every month? >* If we do a major release every month, why is the last minor 4.5.2 in >August 2015 and not 4.5.3 or 4.5.4? > >And if you think there were no commits since 4.5.2? > >git rev-list 4.5.2..HEAD --count >77 > >Branch 4.4: >git rev-list 4.4.4..HEAD --count >8 > >At the end users are more confused, which version to take. We are >dealing with _infrastructure_. > >We must rethink the major release cycling, if it impacts minor releases. >I need a stable cloud aka lots and lots of minors and those now. > >Regards >René >
