[Bioperl-l] Bioperl versioning

Chris Fields cjfields at uiuc.edu
Tue Oct 24 12:45:25 EDT 2006


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

Sorry, my point was that when Audrey T. uses '6.2.13', her $VERSION is
'6.002013'.  So maybe we should follow a similar convention.  Seems easier
and less confusing to me, at least.
 
> 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?

I would go for the clean break if it follows perl/CPAN convention.
'1.60_10' looks like '1.60.10', not 1.6 or 1.6 RC1, so it's too confusing.

If we can use '1.00600x' for 1.6, 1.6.1, etc, and '1.006000_00x' for 1.6
RC1, 1.6 RC2 etc then that would be consistent and perl-compatible. 

BTW, the reason I looked at Pugs was to see what some of the Perl6
developers were using.  Who knows; they'll probably change it!

...

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

So you obviously feel strongly about it!  ;> 

I don't have a problem as long as we stick with doing this from now on (i.e.
have a consistent versioning scheme, release policy, CPAN release policy,
etc).  Would be nice for Jason/Brian/Hilmar to chime in as to the reasoning
behind the older versioning scheme.

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



More information about the Bioperl-l mailing list