Fields, Christopher J | 13 Feb 16:18 2013

[ANNOUNCEMENT] BioPerl Future Development


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