+1 Wei
2013/5/14 Hugo Trippaers <htrippa...@schubergphilis.com> > 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. >
