[Bioperl-l] BioPerl 1.6 RC1

Chris Fields cjfields at illinois.edu
Sat Jan 3 23:26:41 EST 2009


(cc'ing this to Gabriel and Jason):

On Jan 2, 2009, at 4:52 PM, Hilmar Lapp wrote:

> On Jan 2, 2009, at 10:40 AM, Chris Fields wrote:
>
>> Bio::PhyloNetwork [...]  Does anyone think we should leave this out?
>
> I would rephrase the question. I think it's a very valuable addition  
> to BioPerl, and the above may be understood as a vote on that, which  
> AFAIAC is not a vote we need to have.
>
> Instead, I would ask the following. Generally, i) are there any  
> opinions on whether the Bio::XXX root namespace should be  
> permissively expanded, and ii) should new modules that have not been  
> reviewed yet by core devs be included in a stable release.  
> Specifically with respect to Bio::PhyloNetwork, are there opinions  
> on i) moving or not moving this to the Bio::Phylo::Network  
> namespace, and on ii) harmonizing or not the API as much as possible  
> with the Bio::Tree APIs.

On Bio::XXX root namespace expansion: this popped up recently with  
Bio::Microarray and was discussed on the list.  In general I think any  
expansion of Bio::XXX should be 1) actively discussed on list (i.e.  
not just assume a non-response means support) and 2) supported by the  
active core devs.

On reviewing core modules for inclusion in a stable release: we simply  
can't support something that has an unstable API.  We are planning on  
a separate bioperl-dev which can act as a testing ground w/o stifling  
regular bioperl-* releases.  The plan is to also move untested modules  
there.

On Bio::PhyloNetwork specifically: could renaming that to  
Bio::Phylo::Network lump or confuse these with Rutger's Bio::Phylo  
modules?  I can't specifically speak for Bio::PhyloNetwork's API and  
how it coordinates with Bio::Tree APIs but Gabriel or Jason could  
possibly chime in.  They seem to use various Bio::* modules but mainly  
inherit Bio::Root::Root.

> (Chris - you would probably agree that the publication neither  
> answers the above questions, nor guarantees for the API's stability.)

Yes, 100% agree, though I feel publishing should put the onus to  
support the module on the module author, not the core devs (which  
makes me wonder if it would work better split off from core at some  
point).

I'm not sure what we should do at this point late in the game, but I  
would support pulling it and leaving it in trunk until a decision is  
made, then adding it back in a point release at a later point.  I need  
to know something soon, though.  I already have RC1 out; RC2 is to be  
tagged in the next day or two, and I would like to get a final release  
out in the next few weeks (as well as create 1.6 branches for bioperl- 
db, bioperl-run, etc).

chris

> 	-hilmar
> -- 
> ===========================================================
> : Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
> ===========================================================



More information about the Bioperl-l mailing list