Hopefully you don't remember this (success breeds complacence), but a couple of years ago the Parrot project had an extended debate about version numbers. What's a major version? What's a minor version? What does a simple set of numbers encode and communicate about API changes and backwards compatibility and security updates and the need to upgrade?
Those are all good questions, if misguided. The intent behind those questions—and the desire to cram all of that information into a couple of integers and a couple of dots—comes from a genuine desire to communicate effectively with users.
For all of the problems with stuffing extra conceptual weight in a couple of numbers, everyone can agree that version numbers can communicate one thing effectively: which version is newer. While not everyone can remember that Perl 5.8.0 came out in July 2002, it's fairly obvious that Perl 5.14 is newer than Perl 5.8.0. The Perl 5 numbering scheme satisfies that single important criterion, but it could be better.
Consider the case of Ubuntu GNU/Linux releases. While it's obvious that Zealous Zebra is much more recent that Bowdlerized Bonobo, it's not as easy to tell when either one came out (and what happens after the Zebra stampedes off to a nice quiet pasture somewhere as Autonomous Asparagus appears fresh and new?). Fortunately, these releases have code numbers as well: 10.04 is older than 10.10, and 11.04 is newer than both. The additional tag of LTR indicates that certain releases will have longer support periods than others, but that numbering scheme has several advantages.
Apple has a similar codename scheme for Mac OS X releases, where most of the talk seems to prefer the code name (Lion, Pancake, Squirrel) to the version number. One problem with this system is that comparing version names is difficult because Pancakes and Squirrels belong to such different ontologies.
Perl can't easily change to a yearly numbering scheme (the gyrations version.pm already undertakes are nothing if not heroic), but adopting code names in addition to the standard 5.16, 5.18, 5.20 numbers might improve the ability to see at a glance how new or old any release of Perl is.
If I were to do this, I'd use an alphabetical scheme named after flowers or something equally non-offensive: Alyssum, Bluebonnet, Crocus, et cetera. By the time Perl 5.68 rolls around, the alphabet can start over. This alphabetical approach also offers interesting branding possibilities for enhanced distributions such as Strawberry Perl and Task::Kensho.
(Another option is to include the number of the year of the first release of a new major series when talking about the name in a context where compatibility and obsolescence is relevant, but what fun is that?)
This is stupid, seriously, having names is an exercise in masturbation. They communicate nothing, and are seemingly only fun.
I am ok with a Linux distro using "dated" releases because quite frankly semantic versioning makes no sense for an operating system. They house MANY API's, most of which are not unique to that distro.
I am also ok with things like wordlists, and and rule sets using dates, because they tend not to have an API.
and I think http://semver.org/ does a good job, and people need to stop arguing over what semantic versioning means.
Good thing regular masturbation has proven health benefits. :)
Codenames can have benefits too. For example, when searching for anything Ubuntu related it is very helpful to append the codename. Appending "natty narwhal" to almost any search I do greatly increases the utility of the results. Perl would only get this benefit if articles referred to the codenames on a regular basis though.
Others have proposed using codenames, but I agree that they need a theme and they need to be in alphabetical order. I don't want to have to think about which codename is newer than another.
Why not to the day as in 2011.08.03 ? ;)
I do that with CPAN distributions, where I might upload a new version every day for a couple of weeks but then go months without updates. In terms of Perl 5.x, the quarterly release schedule seems to ask for less date specificity.
These version numbering arguments are all the result of attempting to cram too much information into an ordinal sequence. These attempts are almost always a mistake. A simple monotonically increasing value is all that is truly needed. Attempting to do more leads to tears and bitter arguments and serves as a canonical example of one of Cicero's 6 mistakes of man: Refusing to set aside trivial preferences.
The release notes are the proper place to carry all the semantic values that we try and cram into the version number. A good title line, and an concise abstract in the release notes can be used to carry more of the info.
YMMV
"it's fairly obvious that Perl 5.14 is newer than Perl 5.8.0"
not necessarily - 5.14 is less than 5.8 numerically.
and the Ubuntu releases didn't start off being in alphabetical order IIRC...