[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