[Bioperl-l] Priorities for a bioperl-1.6 release
cjfields at uiuc.edu
Wed Feb 13 16:05:16 EST 2008
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
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.
More information about the Bioperl-l