I don't believe in version numbers, at least to tell you anything other than one release is more recent than another. A significant segment of programmers which disagrees: some people really won't believe that Perl 6 actually exists until someone slaps the mythical 1.0 (or 6.0?) tag on Rakudo.
(Usually I put on my philosopher hat and suggest that, as far as ontological arguments go, existence of a thing usually precedes the need to argue whether that thing looks there in your living room, but programmers have a weird deontological attachment to labels, where it's okay for a beta not to work because it's a beta. Kant's Software Development Process within the Limits of Reason Alone is a long discredited hoax created by bored CMU students in the early '80s.)
"1.0 means stable", I hear. 1.0 means "usable" or "mature" or "complete". Legions of enslaved programmers await that glorious day when we pry open the hatch of their galleys and smite their chains and allow them to use software every commit of which has been public for years. Apparently slapping a version number greater than 1 on something summons angels.
With no small irony do I admit to helping perpetuate the practice of releasing software which does not, in one sense or another, actually exist in a usable form. You've used it too. I use it every day. It gets millions of uses, and (or so you might believe), the entirety of Western Civilization and some of the East too might crumble if Serious Businesses realized that it's not really usable.
This is the most useful piece of software I've ever written. It's even part of the Perl 5 core (and it's been there for years, darn their reckless endangerment of Serious Corporations everywhere)! It's Test::Builder, currently at version 0.96.
If you sneeze at it funny or scrape your chair or if you passed by someone on the subway who owns a ferret or something, it might break and delete your data and set your server room on fire and certainly you can't rely on it, because who knows what evil lurks in the spaces caused by that missing 0.04!
It gets worse; T::B has infected the CPAN as well. We'll have to excise it from every corner of every test module and every build or configuration dependency. You just can't trust its beady eyes. What nine year old can you trust?
I know, I know. You think you can make it work for your platform. You've run its tests and you've skimmed its code and you've looked at its bug queue and you've read its documentation, and you truly believe that—in this one case—you can get by with using software which doesn't exist in a useful, usable form because you're a grown up software developer and you know how to evaluate things for your own purposes. Besides, even RHEL includes it as a package, and you know they're still waiting to see if this desktop computing thing will ever take off. (Sure, maintaining backward compatibility with Hollerith cards is a pain, but have you seen the size of those support contracts?)
You might try that, but you'd be wrong. After all, who are you to decide what might work for your specific environment? You're merely a professional with training and experience and local information on your business requirements and coding standards and your own common sense and good judgment.
Who would ever believe you over a monotonically increasing real number?
The solution is clear. If we want to solve the software crisis, we should reclaim from our hard drives the imaginary software sucking up otherwise valuable inodes. The bad news is that we'll have to delete perl5i (but the good news is that we'll finally be rid of that pernicious iPad).
You're technically correct (the best kind of correct), but the people don't actually care about the numbers, they care about what they think they say. 1.0 is associated with a certain degree of stability, like 1.2 not throwing a third of the API overboard again.
If I know "with 1.0 (or 4.7 (or 194.5934.94_1)) we intend to try to stay as back-compatible as possible and won't break too many things unless we absolutely have to, and keep major API changes to 2.0+" I'm thinking "Aha! That's what I have to watch out for to review it for applications in my project." With a technical debate about version numbers (if it had names instead of numbers, we'd be arguing about that instead) all I'm left with is, well, basically no information besides "Well, try it and see." And yes, I know the statement above contains many vague parts. But even a vague plan of what the Perl 6 community is aiming for would be at least something. If they're not aiming for anything like that yet, that's alright as well.
I agree that it sucks that people give 1.0 too much meaning. But do you really think they care about the actual number, and not the (for them) implied longevity in contrast to a 0.* release? After all, that's the part the outsider *can't* judge for himself. He can evaluate Rakudo now, but how does he know what parts will last how long? It might work well in my environment, but what if the core is refactored and it suddenly doesn't perform? How can someone outside the community judge that?
phaylon - I think I know what chromatic will answer here - Rakudo has a defined deprecation policy. I kind of agree that this is better then the tradition of implying a policy from version numbers, numbers cannot carry the same amount of information as a policy document, but at some point we'll have to name (or number) the policies so that we don't need to reread them again and again for every small CPAN dependency - and then we'll be back with a few discreet points, but with a better definition this time. If we all were able to agree what deprecation policy should be related to the 1.0 version we'd be already there - but this is not possible.
zby,
The question is not so much about Rakudo, but more about Perl 6. I'm sure Perl 6 isn't done yet either. Many things are tried out by implementation in Rakudo for the first time, so it's hard to tell if it'll work out. This might be why many people seem to wait for a first near-complete implementation for getting into it.
Googling for "Rakudo Deprecation Policy" didn't lead to any results for me. Might it be useful to add this to the Project Status section on the Rakudo site?
And again, ignore the numbers. Nobody cares about those floating point values, only their implied meaning. They're just symbols.
I too have never really understood the fascination with 1.0. For a start, real programmers should start counting at 0 anyway. :)
But also, I feel that the change from 0.x to 1.0 should be done for the same reasons as 1.x to 2.0; i.e. a major incompatible API change, which needs pointing out "this is different".
Being fooled into thinking a version number means something doesn't change the reality that you have to try it in order to see if the software meets your needs. Even if the software community published a plan for the future, who's to say they stick to the plan? Even if they say "no major API changes until 2.0", who's to say they don't release 2.0 next week? But also ... so what? If I've tried version 0.925 and I know it meets my needs, why would I care about version 1.05 unless it had some feature I wanted? And if it did, then I'd still have to verify that that version meets my needs and doesn't break anything just like I would with any other software with any other version number. (Meanwhile, I still have version 0.925 that I've shown to meet my needs. It doesn't disappear because there's a newer version)
But, you're right, having a plan is an important indicator of the community. And the content of the plan isn't as important as having a plan and being communicative. That's what people should look for in software: a good community. Not some magic numbers.
I seem to not be making myself clear, because that's exactly what I was trying to say. Ignore the numbers. People use them to communicate a question and a concern about a long-term plan, and just telling them their terminology is wrong without trying to understand what they try to communicate is a bit harsh.
Version numbers don't communicate that information though!
If you want to decipher a specific version number, you have to read the project's documentation on what its version numbers mean anyway. I say skip all that magic and don't pretend a version number is sufficient to encode information explained elsewhere.