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.
Re:The problem with that mechanism...
schwern on 2007-12-18T01:36:45
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.
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 coincide with major internals reworking. Test::Harness 1.x -> 2.x was moving the parsing into Straps and 2.x to 3.x was the change to TAP::Parser. MakeMaker 5.x to 6.x was my takeover and major internals refactoring. But that's just me. Everyone's got a different idea.
Since version numbers are a poor way to convey stability, and people have been trained that way, I will simply stop using version numbers that people might confuse with stability declarations. I plan to add something to META.yml to explicitly declare stability.What does a date mean? What information can be gleaned "at a glance"?
The release date, that's all. What can be gleaned is that when your installed release came out in 2002 and the latest release is from 2007... maybe you should look into upgrading.Re:The problem with that mechanism...
drhyde on 2007-12-19T00:11:49
A good compromise would be to use X.YYYYMMDD then, where X increases whenever the API changes incompatibly.improving software version schemes
markjugg on 2007-12-20T03:41:09
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 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...Re:The problem with that mechanism...
schwern on 2007-12-22T03:46:13
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 you choose, how is the user to know?
4) It kills the focus on "your shit is old, upgrade" which I like so much.
I would rather have an explicit mechanism, probably as part of META.yml, to convey stability rather than cram it all into a version number. Also the ability to separate bug stability vs API stability.
This also has the nice advantage of automated installers being able to warn you. "You're about to upgrade to an incompatible API!" You could also set automatic API upgrade policies.
Re:The problem with that mechanism...
drhyde on 2007-12-24T20:09:06
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:-)
