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

[Vaclav Petras]

On Tue, Jun 24, 2014 at 5:32 AM, Pietro <peter.zamb at gmail.com> wrote:

> 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.
>
> I agree. The alternative is to end up with release, devel_for_release and
trunk which we already had and we were not satisfied.

>
> > 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?
>
> This would be very useful in making the two branches policy work smoothly.
Let the experiments happen in branch and then merge them to trunk. How
difficult is this in SVN? I remember that for temporal framework Soeren end
up with local code and then he committed directly to trunk. Branches would
be of course just for bigger projects, for example for python3 or for API
changes.

>
> > 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.
>
> I would prefer Git over SVN. It would help me a lot in my workflows (e.g.,
local branch with my commits and then merge to trunk/master). However, I'm
not sure if this is feasible for GRASS now, it seems that move to SVN
happened just while ago. This depends on how difficult would be to use
experimental branches in SVN as suggested above. We should try SVN first.

The true is that a lot of projects migrate to Git and/or they have at least
mirror at GitHub (or some other but usually GitHub) of their repository
(does mirroring work for SVN?). Moreover, because of my GSoC, I'm looking
at some quality assurance online tools and lots of them require GitHub
repository. Also note that Trac >1.0 has a support for Git, although it is
(was?) considered slower.

Vaclav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140624/617bbdb3/attachment-0001.html>