<div dir="ltr"><div><div><div>We knew there would be some overhead with switching to semantic versioning. There is no way to avoid making decisions about which version a given commit should be contribute to if we want to support simultaneous development of multiple versions. With the 3-branch method we are just paying that cost as we develop, rather than requiring someone to sort it all out at release time. If this is really an unacceptable barriar to contributions, then we could talk about switching to single-version development (e.g. only releasing major releases). However, I strongly suggest that we give the current system a few months to try it out before changing it.<br><br></div>Andreas, master should remain as the 5.0.0 branch because it is much easier to cherry-pick commits from master to the other branches than to get rid of api-changing commits that get accidentally pushed to patch. As to "the branch on which most developments happen", I would generally expect this <i>not</i> to be the patch branch, as most interesting changes either add features or break the API.<br><br></div>I agree that this needs to be better documented. I'll work on adding something to the project README.<br><br></div>-Spencer<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 20, 2015 at 10:10 AM, Jose Manuel Duarte <span dir="ltr"><<a href="mailto:jose.duarte@psi.ch" target="_blank">jose.duarte@psi.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
This is indeed a difficult issue. I think that in principle it is a
good idea to keep the separate branches and have a cleaner
developing progress. Thus I supported Spencer's idea of splitting
into patch/minor/master. <br>
<br>
At the same time this system adds to the complexity of the workflow
and especially makes things more complicated for newcomers and that
is an important concern. Also things are less agile: it forces to
think in a rather rigid development scheme that can make things
slower, departing from the release-fast philosophy.<br>
<br>
With the little experience we've had so far we have already seen
issues with it, e.g. there was a pull request merged to master that
should have gone to patch. I can see this kind of things happening
often. Pull requests from new contributors will surely be going to
master if they don't know our policies. For some people git is
complex enough and adding the several branches layer makes things
even more difficult.<br>
<br>
So if we need to rethink this I would support the simple approach of
a monolithic master-only development. In a world of a few core
developers only, the multi-branch option would be fine. For a more
realistic scenario with an open community with new contributors
coming in all the time, simple sounds like the best idea.<span class="HOEnZb"><font color="#888888"><br>
<br>
Jose</font></span><div><div class="h5"><br>
<br>
<br>
<br>
<div>On 19.02.2015 16:11, Andreas Prlic
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Spencer,
<div><br>
</div>
<div>By having the master branch flagged for a future 5.0
release, I am concerned that we are making contributions more
difficult. Shouldn't master be the main branch on which most
developments happen? Our goal is to enable the ease of
contribution and to make frequent releases. </div>
<div><br>
</div>
<div>
<div>There are more than one way of dealing with branches. We
need to agree on one strategy and document this well.</div>
</div>
<div><br>
</div>
<div>Andreas</div>
<div><br>
</div>
<div><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Feb 19, 2015 at 2:09 AM,
Spencer Bliven <span dir="ltr"><<a href="mailto:sbliven@ucsd.edu" target="_blank">sbliven@ucsd.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>As a reminder to everyone, we're currently
maintaining separate branches for patch, minor,
and master which correspond to features for 4.0.1,
4.1.0, and 5.0.0 respectively. One thing that
would really help with this is if everyone can
make pull requests to the correct branch, rather
than accepting the default of master. This can be
done from the compare screen by selecting the
appropriate base branch (on the left).<br>
<br>
</div>
I also recommend maintaining local
patch/minor/master branches, to allow testing with
the correct features. I know this is a bit of a
hassle, but let's at least give it a shot.<br>
<br>
</div>
It is important to never merge master into either of
the earlier branches. If features from master need to
be back-ported to patch or minor, this can be done
with git's cherry-pick command.<br>
<br>
</div>
Cheers,<br>
Spencer<br>
</div>
<br>
_______________________________________________<br>
biojava-dev mailing list<br>
<a href="mailto:biojava-dev@mailman.open-bio.org" target="_blank">biojava-dev@mailman.open-bio.org</a><br>
<a href="http://mailman.open-bio.org/mailman/listinfo/biojava-dev" target="_blank">http://mailman.open-bio.org/mailman/listinfo/biojava-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
biojava-dev mailing list
<a href="mailto:biojava-dev@mailman.open-bio.org" target="_blank">biojava-dev@mailman.open-bio.org</a>
<a href="http://mailman.open-bio.org/mailman/listinfo/biojava-dev" target="_blank">http://mailman.open-bio.org/mailman/listinfo/biojava-dev</a></pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
biojava-dev mailing list<br>
<a href="mailto:biojava-dev@mailman.open-bio.org">biojava-dev@mailman.open-bio.org</a><br>
<a href="http://mailman.open-bio.org/mailman/listinfo/biojava-dev" target="_blank">http://mailman.open-bio.org/mailman/listinfo/biojava-dev</a><br></blockquote></div><br></div>