Using the following class file: $ cat class1.pm package class1; $VERSION = 1.2.3; 1; Here is how things stand today: class1->VERSION $class1::VERSION perl5.10.0 with builtin version 1.2.3 \1\2\3 perl5.12.4 with builtin version 1.2.3 \1\2\3 perl5.14.0 with builtin version 1.2.3 \1\2\3 perl5.15.3 with builtin version \1\2\3 \1\2\3 With this class: $ cat class2.pm package class2; $VERSION = '1.2.3'; 1; it obviously displays '1.2.3' for all releases. Perl 5.10.0 shipped December 18th, 2007. The version object code first shipped in 5.9.1, in April 2005, including the UNIVERSAL::VERSION changes. That code itself was actually committed March 2004 after a nearly two year discussion and many redesigns. I regret that I never updated the POD in UNIVERSAL.pm to reflect that UNIVERSAL::VERSION would return the stringified $VERSION scalar at the time, which would have prevented this discussion. It is in the version::Internals pod > Replacement UNIVERSAL::VERSION > In addition to the version objects, this modules also replaces the core > UNIVERSAL::VERSION function with one that uses version objects for its > comparisons. The return from this operator is always the stringified > form as a simple scalar (i.e. not an object), but the warning message > generated includes either the stringified form or the normal form, > depending on how it was called. I firmly feel that maintaining the status quo where class->VERSION returns the stringified/normalized value is better than what was released in 5.15.3. Returning the contents of the $VERSION scalar means that every single consumer has to figure out whether it is appropriate to use %vd when printing. Both class1 and class2 have the same version; it seems silly to ignore that the author chose different notations to initialize that. John