[Bioperl-l] [ANNOUNCEMENT] BioPerl Future Development

Fields, Christopher J cjfields at illinois.edu
Wed Feb 13 10:18:10 EST 2013


All,

tl;dr: A lot of change is coming.  Be forewarned and be prepared.

This is an 'official' announcement to the BioPerl community on future BioPerl plans.  We have decided to move continued maintenance of Bioperl release series over to the new 'v1' branch.  This branch will be the point where any future versions of 1.6.x code will be released, starting with the (already-scheduled) March 1 release.  The 'master' branch will become the main focal point for future development of BioPerl going into an eventual v2 release, with a focus on performance enhancements, addressing newer technologies like NGS and large data, code cleanup, and simplifying the code base.

We welcome any help with code improvements. GMOD folks? Want to help? This is a good opportunity to address BioPerl short-comings in the code base! 

What this means for anyone using BioPerl currently:

1) We anticipate significant issues if you are relying on the 'master' branch for anything.  To inelegantly state it, the core developers are taking back the 'master' branch for future development. Please please please do not rely on the 'master' branch for stable code; if you are reliant on the BioPerl 1.6.x, make sure to use 'v1'.  We can revisit whether to make 'v1' the default checkout branch if/when the need arises.

2) Expect not to find some modules.  We will be migrating modules requiring external dependencies and other associated chunks of the code base out into their own repositories over the next year to help future maintenance; the eventual intent is to release all of these independently on CPAN.  We will completely remove all code previously marked as deprecated, and we may immediately deprecate additional modules if needed (this will of course be discussed on list).

3) Expect version numbering to change significantly.  Because we are releasing code in separate repositories, I fully expect downstream versioning problems if we stick with the current system (e.g. all bioperl-live modules having the same version).  It will be too much of a headache to sync versions for all modules as this will entail making a full release of all bioperl code, one of the main reasons we are splitting out code to begin with.  At the moment, no specific versioning scheme has been chosen, though I *highly* recommend using X.Y versioning for simplicity (e.g. no more 3-point versions).  This is the standard that Lincoln has adopted for Bio::Graphics and GBrowse.

4) Expect quick deprecation of methods within modules as needed.  These should of course be brought up to the mail list prior to actual implementation, but I would anticipate some things changing as we try to adopt a more consistent method naming scheme.

5) The same steps outlined for bioperl-live will apply for bioperl-run modules.  We will have to decide the best approach to use for those, e.g. whether to separate them out based on task (alignment), application group (NGS, BLAST, RNA), etc. and how these may fit organically with bioperl-live modules where appropriate.

6) Do not expect a new CPAN release of such code until Dec 2013.  Even then it will be in an alpha stage.  We are all busy campers.

We do not anticipate significant changes to bioperl-network or bioperl-db at this time beyond updating them to deal with new changes. 

I'm sure there are many other points that need to be discussed.   Please reply over the next week if you have any concerns. 

chris


More information about the Bioperl-l mailing list