[Bioperl-l] Priorities for a bioperl-1.6 release
cjfields at uiuc.edu
Thu Feb 14 15:36:27 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
> 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:
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.
More information about the Bioperl-l