On 05/14/2013 05:34 PM, 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?
I agree with you. We can't keep supporting an upgrade path which does
everything. Mainly for us as packagers it's a big hell to do so.
We should never allow people to jump a major version.
So if you are on 3.X, you should be able to upgrade to 4.X, but not to
5.X indeed.
We have the package renaming going from 4.0 to 4.1, which is a bit
difficult, but I'm not expecting it to happen again.
Wido
Cheers,
Hugo
P.S. ignore the version numbers, just used some random version numbers to
illustrate my ideas.
