<div dir="ltr"><div><div>We need to keep the most inclusive branch (5.0) named 'master' due to assumptions by many kinds of software. We already have a 'release' branch which contains only the official releases, for those who want to check out stable versions via git. I'm going to go ahead and set up 'patch' and 'minor' branches.<br><br></div>Andreas, thanks for the SourceTree suggestion. I will try that out. It looks like a step up from my current software-of-choice, <a href="http://gitx.frim.nl/">gitx</a> (mac only). Does anyone know a good linux git GUI? I currently use gitk for viewing trees and diffs, but I'd really like something that lets you cleanly see diffs when staging and committing (and ideally enables staging of individual lines & blocks, like gitx).<br><br></div>-Spencer<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 30, 2015 at 7:17 PM, Douglas Myers–Turnbull <span dir="ltr"><<a href="mailto:dmyersturnbull@gmail.com" target="_blank">dmyersturnbull@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 dir="ltr">I support this completely. Alternate names are "stable"/"release" (4.0), "dev" (4.1), and "next" (5.0). The name "master" is pretty generic and might be misleading.<span class="HOEnZb"><font color="#888888"><div><br></div><div>Douglas</div></font></span><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 30, 2015 at 7:16 AM, Andreas Prlic <span dir="ltr"><<a href="mailto:andreas@sdsc.edu" target="_blank">andreas@sdsc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+1 we are not making enough usage of branches currently. And while we are at it, I recommend everybody to use the SourceTree software for managing git commits and branches. Makes life easy.<span><font color="#888888"><div><br></div></font></span><div><span><font color="#888888">A</font></span><div><div><br><div><div><br></div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 30, 2015 at 5:40 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">
+1 <br>
<br>
Sounds like a good idea, if people are familiar enough with git that
should not be very demanding.<br>
<br>
Regarding naming I like the "patch, minor, master" suggestion. Like
that the branch names will stay stable for any version.<br>
<br>
Jose<div><div><br>
<br>
<br>
<div>On 30.01.2015 14:14, Spencer Bliven
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div>
<div dir="ltr">
<div>
<div>
<div>
<div>One of the things I would like to be better about
post-4.0.0 is releasing bug fixes more quickly. For
instance, users were complaining about having to wait
for 4.0.0 to work with Java 8, even through the Java8
bugs were fixed soon after 3.1.0 was released.<br>
<br>
</div>
I think this would be easy to do if we keep three branches
going for versions 4.0.1 (bug fixes only), 4.1.0
(backwards-compatible features only), and 5.0.0 (major api
changes). Pull requests should be made to the appropriate
branch, and changes can always be merged to a higher level
(e.g. the 5.0.0 should always contain all commits from the
4.1.0 branch). <br>
<br>
</div>
Branches could be named pre4.0.1, pre4.1.0, master; or
perhaps patch, minor, master (to match semantic versioning
levels).<br>
<br>
</div>
What do people think? Would the ease of making patch releases
and minor releases be worth the burden of the added
complexity?<br>
<br>
</div>
-Spencer<br>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><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>
<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></div></div></div></div></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></div></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>