Sent from my iPhone
On 14 mei 2013, at 18:28, "David Nalley" <da...@gnsa.us> wrote: > On Tue, May 14, 2013 at 11:34 AM, Hugo Trippaers > <htrippa...@schubergphilis.com> 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. > > > While I generally like this idea - orphaned features have essentially > long-stranded folks on old version with no way of upgrade. Think of > things like Bare metal, Oracle VM, SG in Advanced Zones, etc. For some > of those, I don't see how we'll not have them upgrade from 2.2.x to > 4.2. The sysadmin in me thinks we've done a moderate job of supporting > upgrades in the past - for some core set of services we've done well, > but used anything not 'mainstream' and we have left many folks behind. > A lot of that is pre-ASF legacy that for better or worse we still need > to deal with. > For folks that have used such things, we have essentially abandoned > them on whatever version they used them. I think that this should mean > that we are much more sober in adding features, to gauge how well we > as a community can support those features over the long haul. It also > means that deprecations need to be planned. The way we deprecated > Oracle VM was horrendous IMO. You are actually introducing a second point here. My point was that if we have a stable upgrade path from say version 2.2.14 to 4.0 then 4.1 would only need to have an upgrade from 4.0 to 4.1. So admins would have to do two different upgrades (talking about packages installed on systems) in instead of one as is the case now. Your point, if I'm getting it right is about abandoning features and thereby users. That's something we agree on, we shouldn't so easily deprecate features as we go along. Or at least be very clear about this and explain why. I think this warrants a separate thread to discuss this in more detail. Cheers, Hugo
