+1 Hugo - I think that's a very pragmatic approach. Whilst it would be great to upgrade any version to any other version, I think most people are used to sequential paths for upgrade of server platforms.
Kind Regards Giles D: +44 20 3603 0541 | M: +44 796 111 2055 giles.sir...@shapeblue.com -----Original Message----- From: Hugo Trippaers [mailto:htrippa...@schubergphilis.com] Sent: 14 May 2013 16:34 To: 'dev@cloudstack.apache.org' Subject: [DISCUSS] Backwards compatibility 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. This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
