<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 24, 2014 at 5:32 AM, Pietro <span dir="ltr"><<a href="mailto:peter.zamb@gmail.com" target="_blank">peter.zamb@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Tue, Jun 24, 2014 at 10:10 AM, Moritz Lennert<br>
<<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>
> My proposal would be just two branches:<br>
><br>
> - releasebranchX.Y<br>
> - trunk<br>
><br>
> The release branch would only live throughout the time of a specific release<br>
> and then become legacy maintenance.<br>
<br>
</div>I like your idea just two branches (stable and unstable!). This should<br>
help our users to be less confused by the GRASS version system.<br>
<div class=""><br></div></blockquote><div>I agree. The alternative is to end up with release, devel_for_release and trunk which we already had and we were not satisfied.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="">
<br>
> The question is how to introduce highly experimental stuff. We can open a<br>
> windows between release branches to introduce new stuff in trunk. At one<br>
> point (something like a month before the creation of a release branch) we<br>
> stop any experimentation in trunk and iron out what needs ironing out before<br>
> creating a release branch out of trunk...<br>
><br>
> This risk of that approach is that some feature will not be tested as long<br>
> before release as in your proposal, but it has the advantage that everyone<br>
> just works in trunk, with release branches just created at the time of<br>
> releases. If I'm not mistaken this is more of less how QGIS development<br>
> works, or ?<br>
<br>
</div>Do you think that we can create branches for specific tasks, like for<br>
example I would like to work to make GRASS compatible with python2 and<br>
python3, so I would like to have a branch: python3?<br>
<div class=""><br></div></blockquote><div>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.<br>

</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<br>
> One option would be to have people experiment more in their personal trees<br>
> and commit innovative features to trunk only when in late beta stage. This<br>
> would probably mean switching to git or something like that since it seems<br>
> more adapted to this style of development than subversion.<br>
<br>
</div>Personally I would love to move GRASS to a distributed revision<br>
control system such as git/hg. making easier for developers to make<br>
our branches (e.g.  python3) and share easily experimental and/or not<br>
working code, without the risk of breaking the trunk version.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div>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.<br>

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

<br></div><div>Vaclav</div></div><br></div></div>