On Tue, May 14, 2013 at 1:46 PM, Hugo Trippaers <htrippa...@schubergphilis.com> wrote: > > > 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.
Yes, I did - sorry about that, but I think it is part of the conversation, because in many cases they created the problem. See below as to why. >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. > The problem is that we have many that can't upgrade from 2.2.14 to 4.0 right now. I think 2.2.14 to 4.1 is the closest we'll get, but wouldn't rool out 2.2.14> 4.2 in some cases. (I know, we are ignoring version numbers. I think this is fine if we put a stake in the ground and say we'll get you from 2.2.14 to the jumping off release, but won't test past that) > 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. > Agreed - maybe I'll start that one soon. --David
