[Bioperl-l] trunk version vs. branch version

[Chris Fields]

On Feb 1, 2009, at 7:47 AM, Dave Messina wrote:

> I would think we'd want to set trunk to 1.006001 -- right past 1.6 --
> because
> - it needs to be >1.6
> - it works for the other distros which need to be set to require  
> something
> after 1.6.0
>
> BUT
> - it won't be >1.6.1 (i.e. 1.006100, I think), which is likely to be  
> the
> next release

(Actually, that would be 1.6.100, or the 100th point release, if we  
stick to using numeric version nomenclature.  The vstring version  
v1.6.1 would be 1.006001.  But I see your point.)

The reason I bring this up is simple semantics: we need a way to  
distinguish main trunk from the 1.6 branch for developers.  bioperl- 
live's VERSION should always be ahead of any CPAN releases so we can  
add in a 'use Bio::Root::Foo #.######'  if we want to indicate whether  
one should use the latest code (trunk) vs. latest release.

One possiblity: we could have trunk's VERSION follow directly after  
the latest CPAN release as an alpha, so it would be 1.006000_001.  If  
we decide that an alpha is necessary for 1.6.1, we release  
1.006000_001 and increment trunk to 1.006000_002, otherwise we would  
release 1.006001 and trunk would increment to 1.006001_001.

That has a significant downside: bioperl-live becomes a moving target,  
so any code reliant on changes only in main trunk would have to  
constantly change any version requirements (ick).  Another issue that  
pops up are scripts expecting trunk ('use Bio::Root::Version  
1.006000_001') that would pass for a later point release (1.006001,  
for instance, would pass the '1.006000_001' requirement).  Double-ick.

Lots of potential confusion best avoided completely, so I think that's  
out as an option.

> I'm presuming that it might be problematic to have trunk at or close  
> to 1.7
> and then bump all the requirements backwards to make them work with  
> the
> 1.6.x releases.

We could continue on with the alternating dev/stable (even/odd minor)  
versioning but not release the odd-numbered 'dev' versions to CPAN.   
That would allow us to designate trunk as 1.007.

The downside: do we want to risk another long wait between minor  
'stable' releases?

> But perhaps there are compelling reasons to make the trunk version  
> peri-1.7?
> If so, I'd still argue for something like 1.006900 so we have room for
> 1.7-alpha releases that are <1.00700, similar to what you did for the
> 1.6-alphas.
>
>
> Dave

Kind of what I'm thinking, which is a nicer middle ground (it is  
pre-1.7, and is a stable target).  Anyone else?

chris