Comments on: Version numbers should be boring

By: Joey

Joey — Wed, 21 Apr 2010 03:30:35 +0000

With all due respect, I'm not going to pollute my code with '$VERSION = eval $VERSION', no matter what other nonsense that leaves it open to. Because I would have to accompany that with a comment that said "go read this enormous article, and then you may understand why this eval is here", and I just can't inflict that on someone who has to maintain my code. So, at the moment, you've convinced me that I should avoid versioning my perl modules. Looking forward to something better..

By: Darren Duncan

Darren Duncan — Wed, 28 Oct 2009 07:07:28 +0000

For the last few years, the practice I have followed for the modules I write is to use X.Y.Z version numbers conceptually and in my documentation and as my distro version, and I use the corresponding X.00Y00Z versions in the actual code of my modules for declaration and use. I increment X for a total rewrite (generally I've never incremented X yet), I increment Y for each update that is either of substantial content (which might just be to documentation) or that introduces an API change, either backwards-compatible or not (so far at least 80% of updates are this kind), and I increment Z for just bug fixes or minor updates that don't change the API. My very first release of any module that isn't production ready from the start has version 0.0.0 because it is the first release of a major series, that is a X.0.0, and X is 0; I then typically go to 0.1.0 or 0.0.1 etc for the next release.

By: David Cantrell

David Cantrell — Thu, 13 Aug 2009 14:18:47 +0000

This++

I'm sorely tempted to make the problem go away and just have my release process just set $VERSION=N.YYYYMMDDHHMMSS where I may or may not remember to update N for major changes. Indeed, two of my modules (Number::Phone::UK::{Data|Exchanges}) already do that.

That has the advantage over your method of not requiring a manual sequence number, and also not overflowing a 32 bit signed int.

By: demerphq

demerphq — Thu, 13 Aug 2009 12:20:26 +0000

Ben: I dont think that is completely true. I have worked a number of times on projects where VERSION!=XS_VERSION. I dont recall the details, but it is possible to setup makemaker so that you can have two numbers be different.

By: dagolden

dagolden — Thu, 13 Aug 2009 10:10:03 +0000

In my own code, I include the eval() line even if I don't technically need it (e.g. for '0.46) so that if I ever decided I needed '0.46_01', I don't need to remember to add eval(). My recommendation is intended to be something that you can add once to your code, then stop thinking about ever again except to bump up the number.

By: Sawyer

Sawyer — Thu, 13 Aug 2009 09:12:24 +0000

Alright, so that's for those type of string. I get that.

If you use '0.46' or that sort of schematic, do you still require the eval(), or would you keep it just for good practice?

By: Abigail

Abigail — Wed, 12 Aug 2009 08:47:17 +0000

My biggest peeve with version numbers is that their ordening is non-intuitive to me. I've always seen version numbers as integers separated by dots - and that's how many tools and other people see them as well. For me, '9' is followed by '10'. But in Perls toolchain, version "x.10" is considered to be older than version "x.9". That, and all the stuff mentioned in your article had me recently decide to switch to DNS style version numbers: YYYYMMDDXX, where YYYYMMDD is the date I make the release, and XX a sequence number to be reset to "01" each day (for those cases I spot a typo immediately after putting in on PAUSE). This loses the convention of signalling the impact of the change by updating a part of the version number that isn't after the last dot, but that was a convention that everyone uses differently anyway. With YYYYMMDDXX numbers, there are no dots, no unexpected translations (AFAIK), and every tool and human orders them the same.

By: Piers Harding (piers) 's status on Tuesday, 11-Aug-09 14:11:39 UTC - Identi.ca

Piers Harding (piers) 's status on Tuesday, 11-Aug-09 14:11:39 UTC - Identi.ca — Tue, 11 Aug 2009 14:11:54 +0000

[...] http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/ [...]

By: Ben Morrow

Ben Morrow — Tue, 11 Aug 2009 13:43:59 +0000

You missed the all-important rule for XS authors that the version passed to XSLoader::load or DynaLoader->bootstrap must match exactly the version string MakeMaker compiled into the module. Hence the common idiom


our $XS_VERSION = our $VERSION = "0.01_02";
$VERSION = eval $VERSION;
XSLoader::load __PACKAGE__, $XS_VERSION;

By: dagolden

dagolden — Tue, 11 Aug 2009 13:29:27 +0000

The eval converts the string "0.001_001" to a number, following the rules for Perl numeric literals (which allow underscores for visual separation). The result is the number 0.001001. Without the eval, the string is converted to a number following the rule for converting strings, which stops at the first non-numeric character. E.g.: perl -e 'print "0.001_001" + 0'