[Bioperl-l] [Gmod-gbrowse] Bioperl 1.6 and Bio::Graphics
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?
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