[Bioperl-l] [Gmod-gbrowse] Bioperl 1.6 and Bio::Graphics

Chris Fields cjfields at illinois.edu
Wed Nov 26 15:25:43 EST 2008

On Nov 26, 2008, at 12:37 PM, Scott Cain wrote:

> Hi Chris,
> While the decision ultimately rests with Lincoln (as, presumably, will
> most of the work :-)  I'm not sure I agree that the split needs to
> happen before the 1.6 release.  Consider the case where GBrowse 1.70
> requires a newer version of Bio::Graphics than is available in
> BioPerl.  We would put a version requirement in the Makefile.PL for
> Bio::Graphics::Panel to be some number greater than the current
> BioPerl release and put it on cpan.  Users would then do the cpan
> shell shuffle, and get the right version of Bio::Graphics, and if they
> don't already have BioPerl, they'll get that too (with an older
> version of Bio::Graphics that will be immediately overwritten).  Is
> there a flaw (or horrible user experience) in my thinking?
> Scott

Sorry Scott, forgot to mention it wouldn't just be Bio::Graphics.   
Lincoln also mentioned Bio::DB::GFF and Bio::DB::SeqFeature::Store  
(basically anything Gbrowse-related) would be included, so maybe bio- 
gbrowse or similar would be a better name.

If you like we could postpone a split (less work for the release).  A  
split bio-gbrowse release would just overwrite the older modules as  
you mention.  However, I plan on having regular point releases to  
CPAN; how do we want to handle Gbrowse-related bug fixes in a point  
release down the road, after a Bio::Graphics split?

Do we stop Bio::Graphics fixes at a certain point after a post-1.6  
split so an installation script always finds the latest  
Bio::Graphics::Panel?  Or do we want to merge those fixes into the  
point release regardless, just in case?


More information about the Bioperl-l mailing list