Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

schwern
  (email not shown publicly)
http://schwern.net/
AOL IM: MichaelSchwern (Add Buddy, Send Message)
Jabber: schwern@gmail.com
Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Monday December 17, 2007
06:42 PM

ISO date integer versions

[ #35127 ]

There's been Yet Another v-string/version-string problem on p5p. This time it's a change to the ill fated $^V variable. Instead of being a detested v-string it's now a slightly more sane version object. Trouble is, this is Yet Another incompatibility which now makes $^V even less suitable for checking the version of Perl than it ever was before.

Just use $].

Which brings me to my point... getting version numbers juuuust right is complicated and never seems to quite work. This is why I stick with floating point numbers, but even they have issues as many folks want "5.10" to be greater than "5.9" which requires special comparison functions and must be expressed as strings or objects. And then you have to guess which comparison style the version in question is using. Oh, and the occasional floating point error.

I've long held that when faced with a wide array of versioning possibilities, such as CPAN, there are only two important attributes of a version:

1) Versions compare as simple numbers.
2) Versions always go up.

Don't follow those rules and it's a nightmare. I once had to write a version comparison function for a Linux distribution. They didn't enforce any versioning standard on the rpms. This lead to such gems as "5.5beta" and "1.1g" and "5.4pre1". Special case after special case.

Nothing else can be gleaned from a version number without specific knowledge of that project's development style. What does version 1.0 mean? 2.0? Is a jump from 1.0 to 2.0 significant? How significant? Are odd numbered releases considered developer releases? Who knows?!

A related problem is how do you convince users to upgrade? When everyone's perception of how much difference there is between versions is different, how do you express to them the urgency of an upgrade?

Car manufacturers and Microsoft figured this out long ago, you use dates. "What, are you still using the OLD 2004 model?! BUY the NEW 2008 model or I'll EAT MY HAT!!" Microsoft products remind you of this every time you start them up with a big "Microsoft Word 2005" splash screen. It's subtle and brilliant marketing. Let's take advantage.

ISO integer dates. YYYYMMDD. 20071217. They compare as simple integers. They always go up. They date a release. They don't lose any information between string and number conversion (ie. 5.70). They don't have the normal problems of remembering and conveying a long version number as we're already used to dealing with dates. Need to shove out two versions in one day? Stick a .01 at the end.

I think I'm going to change my modules over to this.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

ISO date integer versions 7 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Is that many people are trained (and thus find it "intuitive") that the first number communicates the "stableness" of the module.

    0.xxxx vs 1.xxxx etc

    What does a date mean? What information can be gleaned "at a glance".

    • Is that many people are trained (and thus find it "intuitive") that the first number communicates the "stableness" of the module.

      You're right, and it's a false connection. In fact, 1.0 is often the LEAST stable, you want 1.01. And then everyone has different ideas about what an integer version jump should mean, case in point this comment about Text::Metaphone 2.0 [perl.org].

      And then does that mean *API* stability or *bug* stability?

      For me the 0.x -> 1.x jump is API stability and future integer jumps usually coi

      • A good compromise would be to use X.YYYYMMDD then, where X increases whenever the API changes incompatibly.
        • I like the spirit of the original post, but agree with drhyde that API stability changes are also important to communicate.

          Too often cruft is added and software becomes more complex in the name of "backwards compatibility". I've done it.

          Something like the use only [cpan.org] system seemed like a good idea to address this, but it never caught on, and I admit to not adopting myself.

          Perl 6 has some related features built-in, but it will be a while still before that's ready for production use...
        • Problems with that.

          1) 8 decimal places edges into the realm of floating point error.

          2) It has the string vs float problem.
                  2.20071220 is different from "2.20071220".
                  Combined with #1 this can be trouble when comparing versions.

          3) The meaning of X is still arbitrary. Even if the user realizes that it
                  indicates stability, specifically API stability, is 3 incompatible with 2?
                  Which ever answer yo
          • wrt floating point error, just chop the 20 off the year. I'm gonna be dead by the time it matters, so I don't care :-)
  • ... since I'm more worried about folk thinking the "2006" release is old and unmaintained when it is "just working" :-)
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.