[Bioperl-l] Priorities for a bioperl-1.6 release

Chris Fields cjfields at uiuc.edu
Sun Mar 23 14:17:56 UTC 2008


On Mar 18, 2008, at 10:32 AM, Sendu Bala wrote:

> aaron.j.mackey at gsk.com wrote:
>>> Or is the split intended to be 'core' == "anything and everything
>>> that was in 1.4", '????' == "everything else"? In which case,
>>> what's a good name for "modules created after 1.4"? 'crust'? ;)
>> Nah, "icing".
>> a module "use" map might be very useful to help identify "core" vs.
>> other layers of mantle/crust/icing.
>> http://www.perlmonks.org/?node_id=87329 http://search.cpan.org/src/NEILB/pmusage-1.2/
>
> Thanks for those. Neither could quite cope with BioPerl, but I've  
> munged
> them together and hacked up 'module_usage.pl' which I've just  
> committed
> to the maintenance directory of bioperl-live.
>
> module_usage.pl ../Bio
>
> Produces:
> *warning, may crash your browser; download it and view in a dedicated
> image viewer*
> http://bix.sendu.me.uk/files/module_usage.jpeg
> http://bix.sendu.me.uk/files/module_usage.txt
>
> ...
>
> I haven't done any full analysis along these lines and leave as an
> exercise for the interested reader for now ;)

I'm coming into this late (just got back) but I agree, this would be  
very useful.  Your updates based on Aaron's comments help quite a bit.

> Chris Fields wrote:
>> http://www.bioperl.org/wiki/Talk:Proposed_1.6_core_modules
>> I'm pretty flexible on any of that; it's a proposal only and I think
>> some of it may be wrongheaded, but hey, I'm willing to take a few
>> rotten tomatoes.  The key issue is we should try to work out what we
>> mean by 'core' or the core library.  I have a rather extreme view of
>> it as being the bare essentials without external, non-perl core
>> dependencies (only SeqI/PrimarySeqI, AlignI, AnnotationI, SeqFeatureI
>> and required modules for those classes) but I'm sure others would
>> lump in parsers, DB functionality, etc.  I basically suggest placing
>> those (and any stable but potentially non-core code) in a
>> 'bioperl-main', with any unstable or untested code going into a
>> 'bioperl-unstable'.
>
> My thoughts are along these lines:
> # I agree that core should have no external dependencies
> # I agree that it might mostly be interfaces
> # It should represent a framework with all the interfaces (that have
>  stable APIs), directory structure and base classes that everything
>  else relies on
> # It might not do much useful bioinformatics, but provides just about
>  everything needed for a dev to create a new module that does

Yes, that's essentially the idea.

>> In essence, bioperl-main would require core and resemble a stable
>> release; bioperl-unstable would require bioperl-main (and core) and
>> resemble a dev release.  Not sure how versioning would go or if this
>> is a viable option at all, but it's worth discussing.
>
> # I agree that this 3-way split seems reasonable
> # bioperl-main would consist primarily of the 'leaves' of the module
>  tree, mostly parsers and the like which, whilst 'stable' and tested
>  should still be split away from core because the data sources they
>  parse could change format slightly
> # bioperl-unstable, better bioperl-bleed, would feature brand-new
>  stuff, be it new parsers for totally new formats, new APIs that do
>  something not thought of before etc. When they are complete, bug-free
>  and have stood the test of time they get moved into bioperl-main.
>  (It is not a place for all new commits; bug fixes to something in
>  bioperl-main would be committed to bioperl-main)
> # The current splits (bioperl-run, bioperl-network etc.) do not get
>  their own core and bleed variant. Anything they need for core
>  functionality would enter the single bioperl-core, anything new
>  would enter the single bioperl-bleed, and anything stable would
>  be in their own bioperl-[package]
>
> Discuss :)

We can work on updating the plan via the wiki as well as the mail  
list.  I find it easier to track; we can always link back to the mail  
list when needed.

http://www.bioperl.org/wiki/Proposed_1.6_core_modules
http://www.bioperl.org/wiki/Talk:Proposed_1.6_core_modules

chris



More information about the Bioperl-l mailing list