[Bioperl-l] [ANNOUNCEMENT] BioPerl 1.6 release agenda
cjfields at illinois.edu
Fri Nov 21 14:12:59 EST 2008
Apologies in advance for the very long post. This will be placed and
organized on the wiki (links below) for those who don't want to wade
through the entire email.
I'm putting together the general priority list for the BioPerl 1.6
release. Following are a number of items or proposals I think need to
be addressed. This list is neither meant to be comprehensive nor does
it represent everything that must be completed for the next immediate
release, but indicates issues I believe need to be addressed prior to
the release. The end game is to start setting and prioritizing goals
for 1.6 and future releases. I'm sure that I've missed or glossed
over a few things (and possibly missed the mark completely on others),
so feel free to speak up!
All comments are welcome. If there are any additional concerns or
items now is the time to mention them so they can be addressed.
Comments can be made here or be added to the wiki release schedule
discussion page (relevant comments on the mail list thread will be
Also, if anyone wants to work on certain items, please indicate so
here or on the wiki. Items 'locked down' for the release series
(along with relevant devs working on them) will be posted to the main
release 1.6 page (accessible only to wiki sysops):
I would like to continue discussion for the next week or two, allowing
some time for the Thanksgiving holiday, then lock down release
priorities soon after with the goal of releasing 1.6 within a
reasonable time (2-4 weeks if possible).
Bio::Graphics and Splitting BioPerl:
1a) We are planning on splitting up bioperl into smaller (more
manageable) subdistributions; this will mainly occur after 1.6.
However, GBrowse-related modules (Bio::Graphics, Bio::DB::SeqFeature,
Bio::DB::GFF) are undergoing rapid development, much more than the
rest of the bioperl modules. Therefore I suggest we test the waters
(so to speak) and split those off prior to the 1.6 release into their
own distribution. This will allow Lincoln and the GBrowse crew to
proceed with development on those bits of bioperl independently; the
only thing required would be a compatible bioperl release, preferably
in CPAN. If needed this can be tested in a release candidate prior to
a full release.
1b) If we split off Bio::Graphics and related, we should sort out
versioning schemes issues for these subdistributions prior to
splitting them off. Should they be completely independent versions or
be tied in to core (i.e. be 1.6.x, which would be expected to have a
requirement for bioperl 1.6)?
1c) At this point I am considering the other bioperl distributions
(db, network, pedigree) as independent subdistributions, similar to
what may happen with Bio::Graphics etc. Therefore, these will also
have their own independent release schedule. Once 1.6 is released, we
can work on getting other bioperl-* released to CPAN in fairly rapid
manner so they all correspond to core 1.6, but from that point on they
can follow a separate release schedule.
1d) Should we add an option to install subdistributions in the core
Bugs and bugzilla:
2a) Identify outstanding bugs which need to be addressed prior to
release (I have accepted a couple myself which I've been working on),
or should be addressed sometime in the 1.6 release series (i.e. fixed
in a point release if there are no API changes). I will be adding a
table to the wiki page noted above grouping related bugs with notes.
2b) Add any outstanding issues to bugzilla for tracking.
2c) We need to consider merging the enhancement requests and the
project priority list in some meaningful way (either moving everything
to the wiki, or organizing the enhancement requests for various Bio::*
modules in bugzilla).
3a) Though it isn't critical for the release, we should attempt some
simple reorganization of the test suite to deal with the distribution
split mentioned in (1) above. A significant amount can easily be
accomplished by the 1.6 release, but we need to make sure no tests are
left out or repeated. I have already done some simplification of the
SearchIO tests by splitting them up by parser; we can do something
similar for SeqIO, AlignIO, etc. Dave Messina has already taken up
splitting and consolidating SeqIO tests, so any other volunteers for
AlignIO and other relevant bits would be appreciated. Following is a
simple list so we have some to work with (again, this may change
depending on comments):
3b) Tests specific for parsers/plugins: rename Parent_plugin.t (ex:
SeqIO_genbank.t, AlignIO_stockholm.t). I left the plugin as lowercase
here, which is the naming convention we are using for the module names.
3c) Similarly, if modules belong into one collective group, they can
follow a similar Group_class.t (Tools_Genewise.t). Here the module
being tested is uppercase (not a plugin).
3d) How far do we want to take this? Should Location.t be split up
by the various Bio::Location objects into Location_*.t (and similarly,
Bio::Annotation, Bio::SeqFeature, etc)? Again, not a blocker for 1.6,
should be fairly easy to do, but this will increase the number of test
files quite significantly.
3e) We have a set of BioPerl-specific test functions that Sendu
graciously set up in the bioperl 1.5.2 release. We should actually
wrap these into core (Bio::Root::Test or similar) and have them become
generally available for any Bio::* modules, either as exported methods
in a package or as a full-on class. Similarly, we should add a test
file for the BioPerl-specific test functions using Test::More
functions only. This can possibly wait until 1.7, but it shouldn't be
too hard to implement.
3f) Test coverage is already in place (thanks Mauricio, Nathan,
Sendu, and everyone else involved)!
Developer vs. Stable releases:
4a) After 1.6, no more alternating of 'developer' and 'stable'
releases. The designation is highly misleading, particularly when one
considers how stable current subversion code is compared to the
'stable' 1.4 release in CPAN.
4b) By consequence of losing 'dev' releases, we will need to to etch
out a place so developers can test new code, place untested/
unsupported code which may still be useful, etc. bioperl-experimental
is currently designated as the sandbox for Perl6 development, so I
suggest bioperl-dev (bioperl-here-thar-be-dragoons is too long).
4c) Significant changes to modules already present (API changes, for
instance) should be run on a branch to the relevant distribution.
Point releases vs minor releases:
5a) Release regular bug fixes (no API changes) as point releases.
5b) Small API changes require minor releases. Related: what will the
module split version be (1.7? 2.0?)
5c) Deprecation of modules is decided by the core devs. If the module
is widely used (i.e. Bio::Species) we should go through a routine
deprecation cycle prior to removing the module from a distribution.
Some modules (for instance, DB modules which no longer work due to
changes in remote access such as XEMBL) can be immediately deprecated
and removed in the next release.
Again, comments welcome. I will be posting this to the wiki page
More information about the Bioperl-l