Skip Menu |

This queue is for tickets about the Module-Metadata CPAN distribution.

Maintainer(s)' notes

Attention bug reporters: issues MUST include the version of Module::Metadata that you are running that exhibit the stated symptoms. thank you!

Report information
The Basics
Id: 130780
Status: rejected
Priority: 0/
Queue: Module-Metadata

People
Owner: Nobody in particular
Requestors: JSF [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Applying Module::Metadata (1.000037) to a module defining its version number as a simple valid decimal number with trailing zeroes (e.g. to Math::Trig with $VERSION = 1.20;) the method "version" truncates trailing zeroes returning 1.2 instead of 1.20. Looks like an unintended numification, which IMHO should be avoided.
On Tue Oct 22 08:02:11 2019, JSF wrote: Show quoted text
> Applying Module::Metadata (1.000037) to a module defining its version > number as a simple valid decimal number with trailing zeroes (e.g. to > Math::Trig with $VERSION = 1.20;) the method "version" truncates > trailing zeroes returning 1.2 instead of 1.20. > Looks like an unintended numification, which IMHO should be avoided.
It's not really unintended numification if it's already a number. Basically all of the tools handle this the same way. Generally, version numbers should be defined as strings to avoid this. While it would be possible to maintain the trailing zeros by statically parsing the $VERSION line, I'm not certain we would want to diverge in behavior from existing tools.
With the line $VERSION = 1.20; the author of Math::Trig has stated his intention to work with a decimal version number representation containing a major and a minor part. The fact that he has unfortunately used the NV slot of the $VERSION variable to store the value should not hinder us to find a way to honor his intention. Of course, the expected behaviour is heavily dependent on the definition of what is expected. Looks like your expectation is to show an already interpreted version number. My expectation was to see exactly the same version number that is visible both in the source code and in the documentation - and in both cases there is 1.20 not 1.2. If this Math::Trig would have the version 1.2, too (what is not the case), your method would not allow to distinguish between the versions 1.2 and 1.20 so that a user trying to upgrade from e.g. 1.19 to 1.20 would be led astray because the version after such upgrade seems to be even lower than before - if the version is determined using your method.
On 2019-10-24 00:02:23, JSF wrote: Show quoted text
> With the line > > $VERSION = 1.20; > > the author of Math::Trig has stated his intention to work with a > decimal version number representation containing a major and a minor > part. The fact that he has unfortunately used the NV slot of the > $VERSION variable to store the value should not hinder us to find a > way to honor his intention. > > Of course, the expected behaviour is heavily dependent on the > definition of what is expected. > Looks like your expectation is to show an already interpreted version > number. > My expectation was to see exactly the same version number that is > visible both in the source code and in the documentation - and in both > cases there is 1.20 not 1.2. If this Math::Trig would have the version > 1.2, too (what is not the case), your method would not allow to > distinguish between the versions 1.2 and 1.20 so that a user trying to > upgrade from e.g. 1.19 to 1.20 would be led astray because the version > after such upgrade seems to be even lower than before - if the version > is determined using your method.
1.2 and 1.20 are identical version numbers in Perl. You can easily verify that by observing that both these snippets of code pass (if the version check failed, the code would die: { package Foo; our $VERSION = 1.2 } Foo->VERSION(1.20); and { package Foo; our $VERSION = 1.20 } Foo->VERSION(1.2); Show quoted text
> Looks like your expectation is to show an already interpreted version > number.
The alternative to "an already interpreted version number" is to open up the physical source file on disk, find the bytes that define the $VERSION and manually parse it as a string (by wrapping in quotes and then evaluating). We're not going to do that. To do so would give a different interpretation of the version than what code sees (for example version checks as above). If you want trailing zeroes after the decimal place to be respected in your version, you *must* declare it as a string. Or, feel free to use a v-string or an actual version.pm object, but that leads to further problems. You may find https://xdg.me/blog/version-numbers-should-be-boring/ useful to understand some of the other issues at play.