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

[Pietro]

On Tue, Jun 24, 2014 at 10:10 AM, Moritz Lennert
<mlennert at club.worldonline.be> wrote:
> 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.

I like your idea just two branches (stable and unstable!). This should
help our users to be less confused by the GRASS version system.


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

Do you think that we can create branches for specific tasks, like for
example I would like to work to make GRASS compatible with python2 and
python3, so I would like to have a branch: python3?


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

Personally I would love to move GRASS to a distributed revision
control system such as git/hg. making easier for developers to make
our branches (e.g.  python3) and share easily experimental and/or not
working code, without the risk of breaking the trunk version.

Pietro