[Bioperl-l] trunk version vs. branch version
cjfields at illinois.edu
Mon Feb 2 11:30:36 EST 2009
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 --
> - it needs to be >1.6
> - it works for the other distros which need to be set to require
> after 1.6.0
> - it won't be >1.6.1 (i.e. 1.006100, I think), which is likely to be
> 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
> 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
> But perhaps there are compelling reasons to make the trunk version
> 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
Kind of what I'm thinking, which is a nicer middle ground (it is
pre-1.7, and is a stable target). Anyone else?
More information about the Bioperl-l