<div dir="ltr">Well, it's not <a href="http://semver.org">semver.org</a> versioning, but it is still a system where the parts of the version have well defined semantic meaning. That said, it's definitely more exciting to release 4.0.0 rather than another 3.* version.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 23, 2014 at 2:11 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">In principle that would be ok with me, but is this really semantic versioning? I thought that requires the following version nr system: <span style="color:rgb(0,0,0);font-family:Helvetica,Arial,sans-serif;font-size:14px;line-height:21.6000003814697px">MAJOR.MINOR.PATCH ?</span><span class="HOEnZb"><font color="#888888"><div><span style="color:rgb(0,0,0);font-family:Helvetica,Arial,sans-serif;font-size:14px;line-height:21.6000003814697px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Helvetica,Arial,sans-serif;font-size:14px;line-height:21.6000003814697px">A</span></div></font></span><div><div class="h5"><div><span style="color:rgb(0,0,0);font-family:Helvetica,Arial,sans-serif;font-size:14px;line-height:21.6000003814697px"><br></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 22, 2014 at 2:03 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>In thinking about this issue, I came up with a slightly out-of-the-box solution: keep BioJava at version 3.* indefinitely, but otherwise continue using semantic versioning. So the next version will be 3.2.0.0, signifying a major API change, with 3.2.1.0 being the following feature release, 3.2.0.1 for a patch release, etc.<br><br></div>That means we can leave the biojava3 package names without anyone getting confused.<br><br>Thoughts?<span><font color="#888888"><br></font></span></div><span><font color="#888888">-Spencer<br></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 13, 2014 at 7:38 PM, 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">Hi,<div><br></div><div>I'd argue that a package name is just a name. Most of us use an IDE and auto-complete, rather than manually writing import statements. Most of the time I don;t even look at the imports of a class. It seems there is little to be gained by refactoring package names, besides causing work for everybody who would need to refactor the code to support any new names. </div><div><br></div><div>Going forward my favorite naming convention for new packages names for newly added classes would be</div><div><br></div><div>org.biojava.modulename.*</div><div><br></div><div>The structure modules are a slight exception to the rest of BioJava 3. They always have been mostly backwards compatible to biojava 1 and the fundamental interfaces have seen little change since the old days. </div><div><br></div><div>As such my vote would be not to change any package names, only the name of the jar files that are available for download.</div><span><font color="#888888"><div><br></div><div>Andreas</div></font></span><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 13, 2014 at 8:35 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"><span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
No, the pain is actually in the future.<br>
<br>
Consider:<br>
<br>
Project a has a dependency on biojava-legacy version 1.9.1, package<br>
names org.biojava.*<br>
Project b has a dependency on biojava3 version 3.1, package name also<br>
org.biojava3.*<br>
Project c has a dependency on projects a and b<br>
<br>
Project b updates their dependency on biojava3 to version 4.0, which<br>
doesn't necessarily mean a binary incompatible change for project b,<br>
but it means the transitive biojava3 packages are now org.biojava.*,<br>
same as biojava-legacy<br>
<br>
Project c now runs into RuntimeExceptions because some biojava3<br>
version 4.0 class clobbers a biojava-legacy version 1.9.1 class.<br>
</blockquote>
<br></span>
Alright, that is indeed a problem. So it means that for the new release we can't reuse any namespace ever used before.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Commons Math and Commons Collections are other projects that have had<br>
to deal with this<br>
<br>
<a href="http://commons.apache.org/proper/commons-math/" target="_blank">http://commons.apache.org/<u></u>proper/commons-math/</a><br>
<a href="http://commons.apache.org/proper/commons-collections/" target="_blank">http://commons.apache.org/<u></u>proper/commons-collections/</a><br>
<br>
Rather than move from package names org.biojava3 --> org.biojava<br>
perhaps we should consider going from org.biojava3 --> org.biojava4.<br>
</blockquote>
<br></span>
Instead of keeping a 3 or a 4, how about we use a new namespace, not used before and that doesn't refer to the release number?<br>
<br>
If I understand it correctly, legacy was using:<br>
<br>
org.biojava.bio.* and org.biojava.*<br>
<br>
then Biojava 3 was using:<br>
<br>
org.biojava3.* and org.biojava.bio.* (only in the structure module)<br>
<br>
So there's not much left, but we could be creative for Biojava 4 and successors, some possibilities:<br>
<br>
org.biojava.plus<br>
org.biojava.obf<br>
org.biojava.open<br>
org.open-bio.biojava<br>
org.obf.biojava<br>
org.nbiojava<br>
org.biojava.next<br>
org.biojavaplus<br>
<a href="http://org.biojava.bj" target="_blank">org.biojava.bj</a><br>
<br>
<br>
Or of course stay with the status quo and keep the 3 forever. I'm happy to compromise there, but surely one issue would have to be solved if taking that route: the structure module packages org.biojava.bio.* should be renamed to org.biojava3.* to be consistent. Also the tutorial would still need to be fixed in order not to mention Biojava 3, while explaining why the packages have the "3" in the name anyway.<span><font color="#888888"><br>
<br>
Jose</font></span><div><div><br>
<br>
______________________________<u></u>_________________<br>
biojava-dev mailing list<br>
<a href="mailto:biojava-dev@mailman.open-bio.org" target="_blank">biojava-dev@mailman.open-bio.<u></u>org</a><br>
<a href="http://mailman.open-bio.org/mailman/listinfo/biojava-dev" target="_blank">http://mailman.open-bio.org/<u></u>mailman/listinfo/biojava-dev</a><br>
</div></div></blockquote></div><br><div dir="ltr"><div><div><div><div><div><br></div></div></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></blockquote></div><br><div dir="ltr"><div><div><div><div><div><br></div></div></div></div></div></div>
</div></div></div></div>
</blockquote></div><br></div>