[GRASS-dev] release branch organisation [was: Re: GRASS 7 release planning]

[Moritz Lennert]

On 23/06/14 17:35, Martin Landa wrote:
> Hi,
>
> 2014-06-23 10:56 GMT+02:00 Moritz Lennert <mlennert at club.worldonline.be>:
>
>>> ... so, getting out 7.0 seems to be endless...
>>>
>>> A radical solution might be to change trunk into GRASS GIS 8. Then we
>>> do not need to wait in 7 for API stabilization and can release it "as
>>> is" and go ahead with the planned massive improvements.
>
> I think that there is no need for GRASS 8 at this moment, it's not
> related to GRASS 7 release management. The real problem is that we
> don't have clear list of desired features for GRASS 7. Once we start
> with RC stage we need to be sure that we are close to the final
> release - to avoid RC for months or even several months like happen in
> the past. We should also vote about RFC4 before we start with RC
> stage. Personally I would start with GRASS 8 when there will be a
> clear reason for that.
>
>> This sound ok to me. So, ideally, at all times we should have one release
>> branch and one development branch. Releases can then just be tagged from the
>> release branch which gets only selected, well-tested, not to invasive
>> backports from the dev branch.
>
> That is also reason why I would keep trunk as 7.1 before we start with
> tagging 7.0.0RC1.
>
>> Once we decide that the dev branch is sufficiently different from release
>> that backports become unfeasible, and sufficiently stabilised that we can
>> branch a release branch out of it, we declare the previous release branch a
>> legacy maintenance branch (with only limited bug fixing from that point on),
>> and branch a new release branch.
>
> I would prefer to create just release branches. E.g.
>
> * We start with tagging 7.0.0RC1.
> * We create releasebranch_7_1 from trunk
> * Trunk becomes 7.2 or GRASS 8
>
 >
> * We continue with backports only in releasebranch_7_0 towards final release
> * Development will continue in trunk and releasebranch_7_1
> * After some period we freeze releasebranch_7_1 and create
> releasebrach_7_2 from trunk/releasebranch_7_1.
> * We start RC stage in releasebranch_7_1
> * Development will continue in trunk a releasebranch_7_2.


Ok, so you prefer a solution with three branches (besides the legacy 
maintenance branches), in this case

- releasebranchX.Y
- releasebranchX.Y+1
- trunk

?

This does have the advantage to allow experiments to happen in trunk. 
But it has the disadvantage of having to manage backporting between 
these branches.

My proposal would be just two branches:

- releasebranchX.Y
- trunk

The release branch would only live throughout the time of a specific 
release and then become legacy maintenance.

The question is how to introduce highly experimental stuff. We can open 
a windows between release branches to introduce new stuff in trunk. At 
one point (something like a month before the creation of a release 
branch) we stop any experimentation in trunk and iron out what needs 
ironing out before creating a release branch out of trunk...

This risk of that approach is that some feature will not be tested as 
long before release as in your proposal, but it has the advantage that 
everyone just works in trunk, with release branches just created at the 
time of releases. If I'm not mistaken this is more of less how QGIS 
development works, or ?

One option would be to have people experiment more in their personal 
trees and commit innovative features to trunk only when in late beta 
stage. This would probably mean switching to git or something like that 
since it seems more adapted to this style of development than subversion.

Moritz