[Bioperl-l] [ANNOUNCEMENT] BioPerl 1.6 release agenda

[Chris Fields]

All,

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  
copied over).

http://www.bioperl.org/wiki/Talk:Release_1.6

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):

http://www.bioperl.org/wiki/Release_1.6

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  
build script?

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).

Test suite:
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  
shortly:

http://www.bioperl.org/wiki/Release_1.6

http://www.bioperl.org/wiki/Talk:Release_1.6

chris