Next Release Planning

[Mike Burns]

On Wed, 2012-08-22 at 15:56 +0200, Dave Neary wrote:
> Hi,
> 
> On 08/22/2012 11:02 AM, Livnat Peer wrote:
> > About branching policy I'm not sure if we have one, except for creating
> > a branch before release for stabilization.
> 
> Allow me to rephrase & make this concrete:
> 
> In the GNOME project, modules branch as close as possible to release - 
> usually on the release day, or when making a release candidate. In 
> effect, the developers agree to work on new features only on branches, 
> and the trunk is where most of the pre-release work gets done. Branches 
> get merged back into the trunk when they're ready, and not before - and 
> never when we're in feature freeze.
> 
> We branch a stable branch for fixes to bugs in the stable release, and 
> those are as a matter of course fixed in trunk first, and back-ported to 
> the stable branch. We have time-based stable releases of the stable 
> branch during the first 6 weeks of a release cycle to get those fixes 
> out to distros & users.
> 
> My understanding of what you've said so far is that at some point (long 
> before the August 8th release date), a 3.1 release branch was made, and 
> only bug fixes to features which had been included in 3.1 were added to 
> that branch from that date. In the meantime, feature and bug fixing work 
> continued also on the stable branch, but not all of those bug fixes were 
> back-ported to the pre-release branch. I'm guessing that branch was made 
> when we hit 3.1 feature freeze?
> 
> If my understanding is correct, you then have a period of several months 
> (because of the release date slip) when the 3.1 branch is not moving 
> very much, and everyone is working on the trunk branch, including 
> developing new features. The end result is that when the release is 
> made, there is already a big diff with trunk, and as you point out, 
> cherry-picking bug fixes for inclusion on a 3.1 branch is a lot of work.
> 
> In my mind, the work on 3.2 started when we made the 3.1 branch, in this 
> scenario, so perhaps we're already too late to discuss what needs to be 
> included in the 3.2 release - perhaps we should simply work on 
> finishing/stabilising what we have now for release?
> 
> Again, excuse me if I'm over-stepping bounds, I'm just trying to figure 
> out where the work in the project is getting done, and what that implies 
> for this thread.

According to our release process [1], we stop feature development about
1-2 months (depending on the time frame of the release).  At that time,
we should have version branches created which take only stabilization
and bug fix patches.  

Development for future releases continues during that time frame on
master branches of new features.

[1] http://wiki.ovirt.org/wiki/Release_Process

> 
> Cheers,
> Dave.
>