[Bioperl-l] Priorities for a bioperl-1.6 release

[Chris Fields]

On Feb 13, 2008, at 2:19 PM, Sendu Bala wrote:

> Brian Osborne wrote:
>> You should be careful about the names of these packages. For  
>> example, Bio::Biblio and Bio::Restriction are not "in development"  
>> as the term bioperl-dev implies. They're tried and true. And there  
>> may be sets of modules that are experimental in "bioperl-dev", of  
>> course. Is it possible to have 2 packages, "dev" and "tools"? Or  
>> something along those lines?
>> Calling things by the wrong names leads to confusion, witness the  
>> Bioperl newcomers who would install an antiquated version 1.4  
>> because it was labelled 'stable'.
>
> On the topic of confusion, I think 'bioperl-tools' is a very bad  
> choice since we have Bio::Tools. Why would Bio::Microarray (for  
> example) be in there? (And then we have Bio::Microarray::Tools ...)
>
> Can all of the non Bio::Tools modules currently in the bioperl-tools  
> section of the wiki page be annotated as to why they're there and  
> not in core? Then maybe we can come up with a better name to  
> categorize them all under.
>
> Perhaps we could also annotate the things in core to justify why  
> they should be in core? Is anyone good at creating maps so we can  
> easily see what Bioperl modules are most used (by other Bioperl  
> modules)?
>
>
> Or is the split intended to be 'core' == "anything and everything  
> that was in 1.4", '????' == "everything else"? In which case, what's  
> a good name for "modules created after 1.4"? 'crust'? ;)

I added a modified proposal to the Talk page for the Release:

http://www.bioperl.org/wiki/Talk:Proposed_1.6_core_modules

I'm pretty flexible on any of that; it's a proposal only and I think  
some of it may be wrongheaded, but hey, I'm willing to take a few  
rotten tomatoes.  The key issue is we should try to work out what we  
mean by 'core' or the core library.  I have a rather extreme view of  
it as being the bare essentials without external, non-perl core  
dependencies (only SeqI/PrimarySeqI, AlignI, AnnotationI, SeqFeatureI  
and required modules for those classes) but I'm sure others would lump  
in parsers, DB functionality, etc.  I basically suggest placing those  
(and any stable but potentially non-core code) in a 'bioperl-main',  
with any unstable or untested code going into a 'bioperl-unstable'.

In essence, bioperl-main would require core and resemble a stable  
release; bioperl-unstable would require bioperl-main (and core) and  
resemble a dev release.  Not sure how versioning would go or if this  
is a viable option at all, but it's worth discussing.

chris