[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)?

Frankly, it will be hard for a handful of people (Dave, Brian, and I)  
to justify the existence for every bioperl module or it's placement in  
bioperl-?, but at least we have a start on it.  The page is open for  
editing by anyone (Dave, Brian, and I have already added quite a  
bit).  There is also a discussion page to add to, which is a good  
place for proposals and to sketch out ideas.

I think we should take some time on this to stew over the options  
available, maybe a month or two, and set some deadline for starting up.

> 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 personally take the extreme view of having a very tight core with  
just the basic sequence, feature, alignment, and annotation classes  
(just for maintenance sake); everything else just uses those base  
classes anyway, so I don't necessarily consider them core.

I don't think paring down to that level is feasible for a 1.6 release,  
but moving some of the unmaintained cruft out into a separate  
installation would be a good start.

chris