[Bioperl-l] Bioperl versioning

[Chris Fields]

...
> >> 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/

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

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 might disagree with this though. I think perl people, and perhaps
> unix
> >> people in general, should be used to version numbers like '1.5.2', but
> >> then getting '1.52' from the code since such a number allows simple
> >> numerical comparisons while the former does not. The former is easier
> to
> >> read and understand. This is just how Perl itself behaves.
> >>
> >> Most users who wouldn't expect such a behaviour aren't going to be
> >> checking the version number programatically anyway.
> >>
> >>
> >> BTW. do we have someone with a CPAN account, or should I get one?
> >>
> >
> > It says Ewan Birney is the author of Bioperl - I assume it must be
> > possible to have multiple people have the permissions to update a single
> > package.

As a quick response to the above, I would read 'rel. 1.5.2' as the second
patched release of the second revision (here in a developer cycle) of the
first major release.  I would read 'rel 1.52' as the 52nd release of the
major release (just can't quite make it to version 2, I guess).  I don't
think we can use the latter as it is just too confusing, especially since
we've adopted the 'major.minor.patch' versioning quite early on.  

As for CPAN, I believe there is usually a person or group responsible for
maintaining each distribution.  As Ewan seems to be the point man, you'll
have to ask him.  I suppose it is possible to add more if needed

> How did you get Bundle::BioPerl updated? Did you just ask Chris
> Dagdigian to do it for you? Or do you have access to his account? I'll
> ask Ewan about it.

When I inquired about XML::Simple, I emailed Chris D. via his contact
information from CPAN.  He let me know that adding it would be pretty easy,
so all you need to do is let him know about any errors/additions/deletions.
I think his wiki page also has some contact info.  

Which reminds me, if anyone contacts him, could you make sure that
XML::Simple is added?  I can't remember if it has been.

Christopher Fields
Postdoctoral Researcher - Switzer Lab
Dept. of Biochemistry
University of Illinois Urbana-Champaign