[Biojava-dev] Renaming BioJava3 packages & modules

[Spencer Bliven]

Well, it's not semver.org 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.

On Thu, Oct 23, 2014 at 2:11 AM, Andreas Prlic <andreas at sdsc.edu> wrote:

> 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/20141024/b091bad2/attachment.html>