[Bioperl-l] Bioperl stability

[Ewan Birney]

On Mon, 10 Mar 2003 Luc.Gauthier at aventis.com wrote:

> Hi everyone,
>
> I recently started to work with the Bioperl libraries and one question won't
> leave my mind ...
>
> I am wondering how stable Bioperl can be considered. Some people told me
> that they had to rewrite major parts of their applications after Bioperl
> library evolutions. If I believe what they say, the core architecture
> they relied on changed so much that it was barely compatible with that
> of the release they originally worked with.


Well, of course all software has a tension between moving the software
forwards and keeping backwardly compatible. I have to admit, in my sense
of software evolution bioperl goes to some lengths to maintain backward
compatibility, though of course things do change. It is hard to progress
without change. I have worked on top of software libraries with
considerably more change than bioperl...


First off: you don't have to feel wedded to the upgrade cycle of Bioperl.
It is a completely sane strategy to wed working systems to the working
versions of Bioperl used to develop them and to insulate yourself from
changes. With good use of use lib; etc you can run two or even three
versions of bioperl, migrating scripts across when you like (two is about
as much as most people might like to do though...).  This is precisely how
Ensembl ran (Ensembl ran on a 0.7 branch for about 6 months while the 1.0
branch of bioperl was out), and makes perfect sense.  Don't feel you
*have* to upgrade. If the script works, in no way feel you have to
upgrade. Have a plan for upgrades and a testing environment if there is
any production critical code (which you should have anyway, irregardless
if this is in house code or external!). Again, if you look at any large
system, you will find a similar level of resistance to change, with large
step-like changes happening irregularly for the library code. This is a
completely sane way to run one's life.


Some history; The major stability happened first on then 0.7 release (pre
0.7 it was pretty much a free for all), then there was some changes on the
0.7 to 1.0 release, then the 1.0 to 1.2 release is almost a drop in
replacement, though there are some annoyances (WrapperBase fiasco, to be
fixed in the ever-forthcoming 1.2.1 and Me and Heikki making the wrong
call for the Bio::Graphics dependancy on start/end on sequences).
Depending on when your colleague tried it he could have been badly burnt
or not by one of these changes


These days, we usually we chain functions to the new forms and provide
helpful deprecated warnings on changes, with lots of help for backward
compatibility.


We are planning to keep 1.4 as much as possible backward compatible to
1.2, and by and will in particular listen very very hard to people who
test the 1.3 development series against their existing scripts --- this is
a chance for you to help the process - when the 1.4 release guy starts
posting late 1.3 libraries (just before the switch over to 1.4) etc, you
can *ensure* your scripts are not effected.



Finally, bioperl is open, so at least you can see the code and make
changes if you like and if it is critical. If you don't want to do that
yourself and would like to pay for that comfort, then I can put you in
touch with some consultants (not me, and not associated with me, but who
are good bioperlers) who probably would be happy to ensure this for you
for money, which gives some people the warm-fuzzies...



like all open source projects, bioperl is what you make it; currently
there is a sense of sensible stability but with some very exciting new
features (eg, ontologies) which we hope will be backwardly compatible...



ewan