Bug #13310 for Net-DNS: Version numbering breaks modules using dev versions

Sat Jun 18 17:39:55 2005 Guest - Ticket created

Subject:

Version numbering breaks modules using dev versions

The version numbering scheme like 0.51_01 causes the following common perl syntax to fail with an error about non-numeric value in a numeric comparison: use Net::DNS 0.48; This, for example, causes the SpamAssassin perl Makefile.PL step to emit an error message when it checks for minimum version of Net::DNS. If it weren't for the fact that Net::DNS is an optional module in SpamAssasin this would break the build. The standard way to assign version numbers would be to make the development version to be a floating point number such as 0.5101 and to change the version sub in DNS.pm to be as follows: sub version { $VERSION =~ /^(\d+)\.(\d\d)(\d\d)$/; return sprintf("%d.%d.%d", $1, $2, $3); } It may look a bit ugly to have version numbers like 0.5101, but that's how perl and most modules on CPAN do it. Actually they use three digits in each field, but I don't see that you need to change your numbering scheme that much.

Sun Jun 19 13:44:21 2005 OLAF [...] cpan.org - Correspondence added

[guest - Sat Jun 18 17:39:55 2005]: Show quoted text

> The version numbering scheme like 0.51_01 causes the following common > perl syntax to fail with an error about non-numeric value in a > numeric comparison: > > use Net::DNS 0.48; > > This, for example, causes the SpamAssassin perl Makefile.PL step to > emit an error message when it checks for minimum version of > Net::DNS. If it weren't for the fact that Net::DNS is an optional > module in SpamAssasin this would break the build. >

Which, we both agree is bad :-). Show quoted text

> The standard way to assign version numbers would be to make the > development version to be a floating point number such as 0.5101 > and to change the version sub in DNS.pm to be as follows: > > sub version { > $VERSION =~ /^(\d+)\.(\d\d)(\d\d)$/; > return sprintf("%d.%d.%d", $1, $2, $3); > } > > It may look a bit ugly to have version numbers like 0.5101, but that's > how perl and most modules on CPAN do it. > > Actually they use three digits in each field, but I don't see that you > need to change your numbering scheme that much.

I've been using the underscore to indicate development releases. That way they are not picked up by default when people download dependencies. The idea off course is that there are always some folk that are willing to run development release and second that the cpan testes will at least pick up the development release in their test suite. If there is a way to both signal to CPAN that we are using a development version and make sure that SA does not break when using a development than we are in business. (I do not think, but may be wrong, that the indication above would work, otherwise I'd be using the subversion version as version number). --Olaf

Sun Jun 19 15:49:01 2005 Guest - Correspondence added

From:

Sidney Markowitz <sidney [...] sidney.com>

[OLAF - Sun Jun 19 13:44:21 2005]: Show quoted text

> If there is a way to both signal to CPAN that we are using a > development version and make sure that SA does not break when > using a development than we are in business.

That makes sense but I don't know how to do it either. I've asked on the sa-dev mailing list in case anyone there with more perl and CPAN experience has some ideas.

Sun Jun 19 23:53:14 2005 Guest - Correspondence added

From:

Sidney Markowitz <sidney [...] sidney.com>

I found this in the instructions for CPAN contributors at http://www.cpan.org/modules/04pause.html#conventions "The automatic integration of your work into several indexes and directory trees is not always what you desire. If you want to prevent propagation to places outside of your directory, simply choose a filename that matches /\d\.\d+_\d/. PAUSE will leave such distributions alone: no readme will be extracted, no index will be updated, no symlinks will be created." So you are supposed to do exactly what you are doing when you don't want the files automatically used for updates. At the same time, SpamAssassin is doing the right thing by using the proper Perl statement for specifying the minimum version number. Since the build doesn't break after issuing the error message, I guess it should just be treated as a strange warning which happens to be the consequence of running with an unreleased version of a module. Feel free to close this bug report. If I ever see anyone come up with a better idea, I'll let you know.

Mon Jun 20 07:21:37 2005 OLAF [...] cpan.org - Status changed from 'new' to 'resolved'

Tue Jun 21 04:22:05 2005 Guest - Correspondence added

From:

Sidney Markowitz <sidney [...] sidney.com>

[OLAF - Sun Jun 19 13:44:21 2005]: Show quoted text

> If there is a way to both signal to CPAN that we are using a > development version and make sure that SA does not break > when using a development than we are in business

One of the SpamAssassin developers suggested that if you make the version a number instead of a string then the perl parser will ignore the '_' (see the perldata man page) but CPAN uses a regexp instead of the perl parser and will see it. You still would need to change sub version() as I suggested. Can you check with the CPAN people if that would work?

Tue Jun 21 04:22:05 2005 The RT System itself - Status changed from 'resolved' to 'open'

Mon Jul 11 15:53:38 2005 OLAF [...] cpan.org - Correspondence added

[guest - Tue Jun 21 04:22:05 2005]: Show quoted text

> One of the SpamAssassin developers suggested that if you make the > version a number instead of a string then the perl parser will ignore > the '_' (see the perldata man page) but CPAN uses a regexp instead of > the perl parser and will see it. > > You still would need to change sub version() as I suggested. > > Can you check with the CPAN people if that would work?

I must have overlooked this comment. Sorry for the late reply. I am hesitant to change the version sub. The problem is that there might be other packages that have been coded against the current behaviour and changing the behavior of the version sub might break those. Makemaker does the converstion itself when checking ther prerequisites. Maybe the version checking function in the SA Makefile.PL could use the same routine?? (see http://search.cpan.org/src/MSCHWERN/ExtUtils-MakeMaker-6.30/lib/ExtUtils/ MakeMaker.pm : foreach my $prereq (sort keys %{$self->{PREREQ_PM}}) { # 5.8.0 has a bug with require Foo::Bar alone in an eval, so an # extra statement is a workaround. my $file = "$prereq.pm"; $file =~ s{::}{/}g; eval { require $file }; my $pr_version = $prereq->VERSION || 0; # convert X.Y_Z alpha version #s to X.YZ for easier comparisons $pr_version =~ s/(\d+)\.(\d+)_(\d+)/$1.$2$3/; ) Still open for suggestions though. --Olaf

Tue Nov 15 08:31:17 2005 OLAF [...] cpan.org - Correspondence added

I keep on going with the current numbering and although I close the ticket I am open for alternative suggestions. --Olaf

Tue Nov 15 08:31:18 2005 OLAF [...] cpan.org - Status changed from 'open' to 'resolved'