cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <>
Subject Re: [DISCUSS] Backwards compatibility
Date Tue, 14 May 2013 15:59:52 GMT
On Tue, May 14, 2013 at 03:34:00PM +0000, Hugo Trippaers wrote:
> Hey all,
> We have invested a lot of effort in creating upgrade paths from older releases to the
latest version. As a sysadmin this is one of the things I value CloudStack for. 
> However as a developers there are some drawbacks to this. It means every time we release
a new version we need to QA the entire upgrade path to check if users can upgrade to this
new versions. With the speed and features we are picking up, I'm expecting this to become
a large burden in the near future. My proposal would be to draw a line somewhere. Personally
I think it would be ok to say to a user that wants to upgrade from version 2.2.14 to 4.2 to
first upgrade to version 4.0.x en than upgrade to 4.2.x.  For our code it does not really
matter that much, but it does matter for QA and packaging.
> For QA we can safely assume that the upgrades from 2.2.14 to 4.0 are covered by the 4.0
release. If we run into trouble, we release a maintenance release of that version. QA for
new versions should focus on a stable upgrade path for one or two recent versions and can
"ignore" old versions in the process.  With only a few versions to test against we could also
automate parts of this.
> For packaging it is also great. Especially with the current changes in naming (from cloud
to cloudstack) and potential future changes to integrate better with distributions it becomes
handy  to be able to have short upgrade paths. How reasonable is it to have an upgrade path
for 2.2.14 in the RPM when that rpm is built for RedHat 7.
> I would be in favor of supporting upgrades from the first major release in any series.
For example 4.1, 4.2 and 5.0 should have a tested upgrade path from 4.0. 5.1 would have an
upgrade path only from 5.0.
> What do you guys think?
> Cheers,
> Hugo
> P.S. ignore the version numbers, just used some random version numbers to illustrate
my ideas.

I think that this is reasonable, as long as there *IS* a path to get
from any version X (2.0 and up) to any version Y (4.0 and up).

I'd -1 any approach that doesn't provide a path in all cases (multi-hop
is a path).

BTW, we'll have to document the heck out of this...  we do not want any confusion.  And
frankly, we should even consider throwing an error and not processing
an upgrade that hasn't been tested if we do this.

View raw message