[Bioperl-l] Bioperl versioning
bix at sendu.me.uk
Tue Oct 24 11:26:19 EDT 2006
Chris Fields wrote:
>>>> $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:
'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 (188.8.131.52) - 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...
More information about the Bioperl-l