Next Release Planning

[Livnat Peer]

On 22/08/12 16:56, 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?
> 

+1, I suggest that instead of stabilizing what we have now, we'll send a
release date and a feature freeze (FF) date to the dev lists, and see if
there are any comments about the plan, maybe postponing FF by a week or
so can give us more features etc.
On the agreed FF date we'll create the 3.2 branch and ask all
stabilization patches to be cherry picked to the 3.2 branch.


I think we should discuss now what should happen with the next-next
release :)
after releasing 3.2 we'll have the same dilemma we are having today. How
will we make the decision if the following release is 3.3 or 3.2.1, do
we want to create 3.2.1 on our 3.2 release date and ask for all
stabilization patches to be back ported there? and if we see that we
want to release 3.3 at the end and no need for 3.2.1 will all the cherry
picking be for vane?

> 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.

I think it is a useful discussion and can help us going forward. There
is a great value in your participation and in any experience someone
brings to the table.

> 
> Cheers,
> Dave.
>