[Bioperl-l] BioPerl 1.6 RC1
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
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
> (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
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).
> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net :
More information about the Bioperl-l