[Bioperl-l] Creating PPD's from CPAN Bundles

[Chris Fields]

..
> This doesn't matter; we still claim that bioperl 1.4 is the latest
> stable release. People will continue to chose to install the release
> that is claimed as being stable.

To go back and retrofit Bundle::Bioperl for one particular OS-specific
version of bioperl is, IMHO, not necessary and not productive, especially
since we would have to rebuild the v 1.4 PPM archive and ppd files to deal
with the corresponding Bundle::Bioperl.  It's up to Nathan, really, but I
don't see the point.  

Yes, bioperl-1.4 is considered 'stable,' but when the code is almost three
years old and so many bug fixes have been committed to CVS, wouldn't the
designation 'stable' be in name only?  It wouldn't be an issue if we had
released regular bug fixes and point release for v1.4, but hind-sight is
always 20/20.  Most users I know have moved on to use 1.5.x or bioperl-live.
As an example, GBrowse generally requires the most up-to-date core code
whenever a new GBrowse point release is made since it relies on
functionality and bug fixes present there. 

I can't count how many times I have had to tell someone to update from CVS
(even from v 1.5.1) because BLAST report parsing or GenBank/EMBL/Swiss
parsing is broken in some fundamental way.  If anyone wanted to use BLAST
parsing in Bioperl with output from a BLAST version newer than v.2.2.11,
they need to upgrade at least to v 1.5.1, and more often than not to
bioperl-live.  It is possible that Bioperl 1.4 is still considered 'stable'
for sequence parsing and other functions, but definitely not for more
up-to-date BLAST parsing.  Further, I would suggest GenBank/EMBL/Swiss
parsing in v 1.4 may not work as expected either.  

> 1.5.2 is a developer point release to try out experimental new features.
> It may contain many bug fixes, but because it also contains new things
> it can't be used in a production environment. 1.4 can; most of its
> problems are that some things no longer work because file formats etc.
> have changed since its release, but what /does/ work is at least known
> reliable (presumably).

I agree that we need to push out a 1.6 release as soon as possible, and that
experimental modules or other issues which may break or change API need to
stay on the developer branches.

Judging by the number of bug reports that involve v 1.4 code, the lack of
bug fixes to 1.4, and the age of the v 1.4 code base, unless one is using
software versions that date back to the release at that time, I wouldn't
call v 1.4 particularly stable anymore.  And, as pointed out in a past
thread, it's waaaay too late to start committing bug fixes to v.1.4.  This
fact, along with the huge number of bug fixes we have committed since then,
was part of the impetus to get a new developer version out and start paving
the road to 1.6.  We're doing a tremendous job of that now.

As for bugs, the few reported bugs left in bioperl-live are, more often than
not, rare cases and do not dramatically affect overall core use.  That is,
unless there are some really pressing ones you have found.  You have to
relish the fact that we carry a very large code base that passes all tests
on almost every OS (including WinXP, which I didn't ever expect).  If you
look at past release, that wasn't always the case.

> 1.6 will be tested and polished into the ground, and we can recommend
> everyone install that. 1.5.2, not so much. It contains known bugs.

So did v 1.4; it is no different than other production code.  Just because a
bug isn't reported doesn't mean it isn't there; it just hasn't be uncovered
yet.  For instance, I just fixed a BLAST bug present since v 1.4 which
tossed out the Frame information for PSITBLASTN reports.  You would think
that this would be caught earlier, but it wasn't.

To make a short story long, the best way to resolve these issues is, when we
release v 1.6, we should have someone make regular point releases for core
to take care of bugs and other issues (non-API related, of course).  Any
significant changes to implementation would be on the next developer release
(v. 1.7), which should come out relatively quickly after v 1.6.  That way we
can start plotting (plodding?) our way towards v. 1.8 and beyond.

Christopher Fields
Postdoctoral Researcher - Switzer Lab
Dept. of Biochemistry
University of Illinois Urbana-Champaign