[Bioperl-l] Bioperl versioning

[Sendu Bala]

Chris Fields wrote:
> ...
>>>> Since
>>>> $VERSION = 1.52_10;
>>>> is evaluated to 1.5210, by analogy if 1.60_02 was RC2 before release,
>>>> final release version should be
>>>> $VERSION = 1.6010.
>>> Because they are dealt with separately, I don't think this is an issue
>>> (see above).
>> If you don't notice the dates, or are doing numerical version number
>> comparisons, 1.6002 (an RC) is greater than 1.60 (the release). It may
>> not be automatic, but you can still chose to download the developer
>> releases. Which means if we say to someone 'use Bioperl 1.6 or better'
>> they may choose to get the latest version and think it is 1.6002 when
>> infact 1.60 was the more recent version. 1.6010 solves the problem, is
>> consistent with your 1.50_10 suggestion, and doesn't cause any problems
>> as far as I can see.
> 
> CPAN looks like it can handle 'x.y.z', at least for Pugs:
> 
> http://search.cpan.org/~audreyt/Perl6-Pugs-6.2.13/

'handle'? I think it shows up as '6.2.13' simply because it was uploaded 
with the filename Perl6-Pugs-6.2.13.tar.gz


As you point out, the code has the kind of $VERSION number we've been 
suggesting in this thread:

> From the Perl6::Pugs source, $VERSION for rel 6.2.13 is '6.002013':
> 
> our $VERSION = 6.002013;
> 
> That's also a very perlish-way to do it.  And there are no developer
> versions of Pugs, since it is always under active development.  We could try
> something like:
> 
> our $VERSION = 1.005002_01;

Yes, this was already like one of my suggestions (1.0502_01), but I 
brought up the concern that 1.05 might be < 1.4.

So then we have a question: do we try and fumble a 1.4 compatible number 
by using 1.60_10, or do we have a clean break, remove 1.4 from CPAN if 
it causes problems, and go for the 'proper' 1.006000 (1.6.0) with no 
room for RC numbering, or 1.006000010 (1.6.0.10) - the first final 
release following some 1.006000_001 (1.6.0.01 == rc1) RCs?


> just to tag it as a developer release or release candidate, if that's what
> you want; I'm neutral to that point.  I don't think it's necessary to post
> every RC to CPAN, though, unless you feel very strongly about it.  It just
> seems like more hassle than it's worth, esp. since you've been releasing
> about one per week leading up to a final 1.5.2 (due soon).  

I don't think it would be a hassle; on the contrary it would be very 
useful to know the CPAN distribution actually works. I'm very happy with 
the idea that a release candidate gets fully tested...