Comments on: Version numbers should be boring

By: dagolden

dagolden — Fri, 01 Apr 2011 00:15:51 +0000

That's an interesting discovery. Much of this article doesn't apply to XS modules, as the version comparison between XS and the .pm file happen through different mechanisms than normal version comparison.

By: samlin

samlin — Thu, 31 Mar 2011 23:16:51 +0000

I see many XS modules failing on 5.6.2 when they use your recommended approach. Because the eval results in stringified version of the number in scientific notation, which does not match the decimal format:
$ perl5.6.2 -e 'our $VERSION="0.01"; print eval $VERSION' 1.e-02

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/ [...]