Features Download
From: Fields, Christopher J <cjfields <at> illinois.edu>
Subject: [ANNOUNCEMENT] BioPerl Future Development
Newsgroups: gmane.comp.lang.perl.bio.general
Date: Wednesday 13th February 2013 15:18:10 UTC (over 4 years ago)

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. 

CD: 3ms