[Bioperl-l] bioperl-dev or branch?
cjfields at illinois.edu
Thu May 21 23:40:09 EDT 2009
On May 21, 2009, at 8:51 PM, Mark A. Jensen wrote:
> ----- Original Message ----- From: "Hilmar Lapp" <hlapp at gmx.net>
> To: "Robert Buels" <rmb32 at cornell.edu>; "Chris Fields" <cjfields at illinois.edu
> Cc: "BioPerl List" <bioperl-l at lists.open-bio.org>
> Sent: Thursday, May 21, 2009 9:33 PM
> Subject: Re: [Bioperl-l] bioperl-dev or branch?
>> That sounds all good to me, except that bioperl-dev has Bio/Root/*
>> replicated. It should not, right? If we want to introduce
>> experimental changes to Bio/Root modules, they should go into a
>> bioperl-live branch, right? (Otherwise I'm confused what a bioperl-
>> live branch is for.)
> Well, this is what I'm wondering. For Chase's project, e.g., there
> may be
> mods that need to take place (or be tried out, and possibly
> discarded later,
> which is key) in the core modules, to interface the new stuff with
> the core.
That should probably happen in bioperl-live, then (or a branch
thereof). Don't be afraid to branch off bioperl-live if needed to do
the work. If it passes tests and looks good we merge it back to core
> So experiments may occasionally depend on (possibly radical) changes
> the core--nasty for folks (I expect they are many) that update on
> the core
> regularly and expect changes there to be incremental fixes and/or
> new and
> relatively well-tested functionality. So I do conceive of bioperl-
> dev (rightly
> or wrongly) as a parallel branch of bioperl-live, but not a temporary
> "feature" branch as such. It can and prob should be pretty persistent.
> But read on...
>> So in this picture Chase's project would go into bioperl-dev, main
>> trunk. Users would obtain it by downloading bioperl-dev from svn or
>> as package and simply install on top of a Bioperl-core package,
>> without fear of clobbering stable modules that came with Bioperl-
>> core. Right?
> This is the way I'd love it to work, modulo the exptl core changes
> above. My own tendency in development is to make stuff as separable as
> possible (by specifically overriding core methods in 'Helper'
> modules, for example),
> and if this were part of the bioperl-dev rules of engagement (i.e.,
> no core modules,
> only overrides), then users could count on the behavior you
> describe. Mirroring
> the existing core paths is also key for this expectation.
I think mirroring the paths is feasible, but not copying the module's
name directly. So you could have a Bio::Root::Moose, but not a
>> If that's the idea it makes a lot of sense to me and seems sane.
>> Conversely, using bioperl-dev as another way to branch bioperl-
>> core modules doesn't, though I may be missing something.
> That's the idea in my own private Idaho, here in Georgia.
Same here (from somewhere in corn country).
>> (I hope I'm making sense. Please do say if I'm not ...)
> Me too X 2.
More information about the Bioperl-l