[Biojava-dev] Renaming BioJava3 packages & modules

[Andreas Prlic]

In principle that would be ok with me, but is this really semantic
versioning? I thought that requires the following version nr system:
MAJOR.MINOR.PATCH
?

A


On Wed, Oct 22, 2014 at 2:03 AM, Spencer Bliven <sbliven at ucsd.edu> wrote:

> 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/11c713a8/attachment.html>