Next Release Planning

[Itamar Heim]

On 08/23/2012 09:05 AM, Livnat Peer wrote:
> 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?

I think based on amount of changes / their scope / suggested/requested 
cycle for the release.

another option we can consider is to allow working on both long term 
major release in parallel with short term release.
i.e., have both 3.2 and 4.0 compatibly levels in master, so code can be 
written for both.
not sure other projects do something similar though - usually master is 
a single head going forward.

>
>> 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.
>>
>
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board
>