[Biojava-dev] Renaming BioJava3 packages & modules

Sat Jan 24 23:59:12 UTC 2015

Hi,

a late follow up to this thread from last October. We never really
concluded this discussion with consensus. As such I suggest we settle this
by vote.

Please post your votes by Tuesday at
https://github.com/biojava/biojava/issues/240

If a majority votes for this refactoring, I will do this after the code
freeze on Thursday and before we finalize the release.

Andreas

On Fri, Oct 24, 2014 at 12:44 AM, Spencer Bliven <sbliven at ucsd.edu> wrote:

> 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
>>>>
>>>
>>>
>>
>>
>

-- 
-----------------------------------------------------------------------
Dr. Andreas Prlic
RCSB PDB Protein Data Bank
University of California, San Diego

Editor Software Section
PLOS Computational Biology

BioJava Project Lead
-----------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.open-bio.org/pipermail/biojava-dev/attachments/20150124/eac464f0/attachment.html>