Alright, if we go with 4.0.x maintenance releases, how long will we support the 4.0 branch and how many maintenance releases we want? We should also also decide what kind of releases will be long term or short term (and define what long term would mean, ie. the duration, 3-6 months, 1-3 years etc.), which ones (4.1, 4.2, 5.0 etc) and who will be the branch maintainer, release manager (as we will keep on doing releases we will have 4.x, 5.x, 6.x and sub branches 4.0.x, 4.1.x, 4.2.x. 5.0.x, 5.1.x etc.).
Regards. ________________________________________ From: David Nalley [da...@gnsa.us] Sent: Tuesday, November 13, 2012 6:12 PM To: cloudstack-dev@incubator.apache.org Subject: Re: [DISCUSS][ASFCS40] 4.0 Branch Lifecycle On Tue, Nov 13, 2012 at 4:27 AM, Rohit Yadav <rohit.ya...@citrix.com> wrote: > I've only one concern, if we go for a 4.0.1 bugfix release, since there are a > lot of changes in build system and packaging on master, simply cherry picking > may not work. > I would like to suggest that we drive all our engineering efforts on master > (release wise, build system, esp. pkging are blockers on master), switching > between 4.0 and master may confuse people, I've seen some of my colleagues > now becoming comfortable with maven, yes the build system, so let's not go > back to ant. Maybe we can cut out a 4.0.1 release based on master since there > has not been any major feature or backward compatibility breaking change on > master. Flames, thoughts? > That's the 'problem' with having to support releases, you just can't abandon them. It is a non-trivial amount of work, and there may indeed be patches that can't simply be cherry-picked but if we 'abandon' the 4.0.x branch I fear we send the wrong message. We know the state of the 4.0.0 branch compared to 4.0.0 release, but master is a completely different animal at this point, particularly with regards to packaging - and that raises the QA bar IMO, because it isn't just whether the code works, but if it works in its new deployable form. This overhead also means we should be very conservative about what we actually try fixing in 4.0.x - there are some bugs that are bad enough, to warrant being handled in 4.0.1 but that number is pretty small at this point.
