[Biojava-dev] Renaming BioJava3 packages & modules

Mon Jan 26 09:35:26 UTC 2015

We should also vote on refactoring module names.

https://github.com/biojava/biojava/issues/242

Same deadline for the code freeze

On Sun, Jan 25, 2015 at 12:59 AM, Andreas Prlic <andreas at sdsc.edu> wrote:

> 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/20150126/2341b3f0/attachment.html>