[Bioperl-l] bioperl-dev or branch?

Mark A. Jensen maj at fortinbras.us
Fri May 22 01:51:47 UTC 2009


H-
----- 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.
So experiments may occasionally depend on (possibly radical) changes to
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 mentioned
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.

>
> 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.

> (I hope I'm making sense. Please do say if I'm not ...)
>
Me too X 2.
MAJ


> -hilmar
>
> -- 
> ===========================================================
> : Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
> ===========================================================
>
>
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>
> 




More information about the Bioperl-l mailing list