[Bioperl-l] bioperl-dev or branch?
cjfields at illinois.edu
Thu May 21 23:08:27 EDT 2009
On May 21, 2009, at 8:33 PM, Hilmar Lapp wrote:
> On May 21, 2009, at 7:31 PM, Robert Buels wrote:
>> Just to clarify, it doesn't look like bioperl-dev is actually in a
>> separate repo, it's just separated from bioperl-live as a different
>> distribution, but still in the 'bioperl' repository.
> True, actually, my mistake. I guess I was assuming from the early
> days of cvs that these are actually different repositories. Sorry
> 'bout that.
> So in essence bioperl-dev and bioperl-live are different directory
> trees within the same repository.
> On May 21, 2009, at 5:52 PM, Chris Fields wrote:
>> The key aspect that started this all is to have a lean (read: few
>> dependencies, relatively stable) core set of modules. Other
>> related modules which add additional dependencies could be moved
>> into a bioperl-tools. And (finally) anything lacking the guarantee
>> of API stability would be bioperl-dev. I think several other
>> alternatives came up but these seemed to be the final ones.
>> core = minimal functionality
>> tools = complete functionality (requires core)
>> dev = experimental APIs, etc (requires core and possibly tools)
> I do like this. Am I right that the way we should be looking at this
> is as disjoint subsets that as a total make up BioPerl. So a module
> would be found in one and only one subset, and if I wanted the
> entire BioPerl package I download each one.
> Bioperl-dev then isn't for holding different (e.g., more
> experimental) versions of the same modules that are also in bioperl-
> core (aka bioperl-live).
It's however we want to set it up. I would prefer that we not have a
module share the exact same namespace, but I think we can put
experimental implementations there that could replace something in
core (particularly if replacing something in core could possibly
become a thorny proposition, or if the new code goes unmaintained).
However, as I pointed out before I have done some major revisions on
branch and merged back w/o significant issues (and those that did pop
up were fixed very easily).
> Likewise, each subset then has its tags and branches and main trunk,
> right? (Though hopefully the release tags would be present in all)
> 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.)
Mm, yes, see what you're saying, the Bio::Root modules in dev should
be removed. Was there a particular reason those were present, Mark?
Do they contain anything new? I ran a diff on a few of them and
couldn't find anything.
I think, for the sake of not confusing users module names should be
new and not conflict with a core module's already-claimed namespace.
I think it's okay to have something new with a base namespace like
Bio::Root::*, but the module name should be unique (I have thought of
Bio::Root::Moose, for instance, as a Moose-based Root metaclass, but
that may go elsewhere...).
If the module is intended as a replacement for something in core we
can decide then how to proceed, but (as mentioned above) it could be
something that is worked out on a branch. Seeing how the perl6 and
Parrot projects progress, everything goes to a branch and gets merged
back unless the changes don't work. After merging it gets removed
unless it's a release branch.
> 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?
> 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.
No, we should use branches as normally intended. I had thought about
doing some stuff with FeatureIO in dev but decided against it and will
probably go to a branch when the time comes.
> (I hope I'm making sense. Please do say if I'm not ...)
You're making sense. :>
More information about the Bioperl-l