[Bioperl-l] bioperl-dev or branch?

[Chris Fields]

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.

Yes.

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

Yes.

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

Yes.

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

Yes.

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

You're making sense.  :>

chris