cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <>
Subject Re: Minor releases!
Date Thu, 07 Jan 2016 21:30:58 GMT
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

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

On Thu, Jan 7, 2016 at 12:30 PM Wei ZHOU <> wrote:

> 2016-01-07 15:24 GMT+01:00 Rene Moser <>:
> > 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
> 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é
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message