[Biojava-dev] Renaming BioJava3 packages & modules

[Spencer Bliven]

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.

That means we can leave the biojava3 package names without anyone getting
confused.

Thoughts?
-Spencer

On Mon, Oct 13, 2014 at 7:38 PM, Andreas Prlic <andreas at sdsc.edu> wrote:

> Hi,
>
> 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.
>
> Going forward my favorite naming convention for new packages names for
> newly added classes would be
>
> org.biojava.modulename.*
>
> 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.
>
> As such my vote would be not to change any package names, only the name of
> the jar files that are available for download.
>
> Andreas
>
> On Mon, Oct 13, 2014 at 8:35 AM, Jose Manuel Duarte <jose.duarte at psi.ch>
> wrote:
>
>>
>>  No, the pain is actually in the future.
>>>
>>> Consider:
>>>
>>> Project a has a dependency on biojava-legacy version 1.9.1, package
>>> names org.biojava.*
>>> Project b has a dependency on biojava3 version 3.1, package name also
>>> org.biojava3.*
>>> Project c has a dependency on projects a and b
>>>
>>> Project b updates their dependency on biojava3 to version 4.0, which
>>> doesn't necessarily mean a binary incompatible change for project b,
>>> but it means the transitive biojava3 packages are now org.biojava.*,
>>> same as biojava-legacy
>>>
>>> Project c now runs into RuntimeExceptions because some biojava3
>>> version 4.0 class clobbers a biojava-legacy version 1.9.1 class.
>>>
>>
>> Alright, that is indeed a problem. So it means that for the new release
>> we can't reuse any namespace ever used before.
>>
>>
>>> Commons Math and Commons Collections are other projects that have had
>>> to deal with this
>>>
>>> http://commons.apache.org/proper/commons-math/
>>> http://commons.apache.org/proper/commons-collections/
>>>
>>> Rather than move from package names org.biojava3 --> org.biojava
>>> perhaps we should consider going from org.biojava3 --> org.biojava4.
>>>
>>
>> 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?
>>
>> If I understand it correctly, legacy was using:
>>
>> org.biojava.bio.* and org.biojava.*
>>
>> then Biojava 3 was using:
>>
>> org.biojava3.* and org.biojava.bio.* (only in the structure module)
>>
>> So there's not much left, but we could be creative for Biojava 4 and
>> successors, some possibilities:
>>
>> org.biojava.plus
>> org.biojava.obf
>> org.biojava.open
>> org.open-bio.biojava
>> org.obf.biojava
>> org.nbiojava
>> org.biojava.next
>> org.biojavaplus
>> org.biojava.bj
>>
>>
>> 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.
>>
>> Jose
>>
>>
>> _______________________________________________
>> biojava-dev mailing list
>> biojava-dev at mailman.open-bio.org
>> http://mailman.open-bio.org/mailman/listinfo/biojava-dev
>>
>
>
>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at mailman.open-bio.org
> http://mailman.open-bio.org/mailman/listinfo/biojava-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.open-bio.org/pipermail/biojava-dev/attachments/20141022/d333b979/attachment.html>