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

[Nathan S. Haigh]

Chris Fields wrote:
> ..
>   
>> 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.  
>   
Personally, I think I agree with Chris. The boundary between "stable" 
and "developer" code is somewhat fuzzy, and most posts I've seen to the 
list over the past couple of months regarding things not working were 
due to Bioperl 1.4 being installed.
> 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.
>   
Should an effort be made to commit bug fixes to the 1.5.2 branch after 
it's release and make reasonably quick releases of 1.5.2.x so we don't 
end up in a similar situation with 1.5.2?
> 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.
>   
Maybe it would be safer/better to do this with the 1.5.2 release rather 
than waiting for the 1.6 release?
> Christopher Fields
> Postdoctoral Researcher - Switzer Lab
> Dept. of Biochemistry
> University of Illinois Urbana-Champaign 
>
>
>