On Tue, Jun 24, 2014 at 10:10 AM, Moritz Lennert <mlenn...@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 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev