The problem is that it doesn't look like a date at all (is there any country or region using day of year in their date??). I've never been bothered enough with this though, as I don't use this scheme myself, but have always had a suspicion that this obfuscation is deliberate for some deep reason.
Turns out that it's just a matter of space saving and floating point issue. I'm not convinced though, is x.100513n (YYMMDD, 6 digits + 1 digit serial = 7 digits) really that much longer than x.10133n (YYDDD, 5 digits + 1 digit serial = 6 digits)? Is there a modern platform where Perl's numbers are represented with 32-bit single precision floating point (only 7 decimal digit precision) where it will present a problem when n becomes 2 digit using YYMMDD scheme?
Based on past experiences, since it is unlikely that I will do more than 20 releases in one month (usually even only once or twice a month or less frequently), if I were to adopt a date-based automatic versioning policy, perhaps I'll pick x.YYMMn where n is omitted for the first release, and then 1..9, and then 91..99 (and then 991..999 and so on). This way, most releases have the shortest number of digits. I don't "incur cost" for the first few releases (which anyway will be all there is, most of the time).
1.1005
1.10051
1.10052
...
1.10059
1.100591
1.100592
...
1.100599
1.1005991
...In fact, I bet most modules have only a few releases per year. So how about this scheme, x.YYn:
1.10 - first release of the year
1.101 - second
1.102 - third
...
1.109 - tenth
1.1091 - eleventh
1.1092 - 12th
...
1.1099 - 19th
1.10991 - 20thOr how about x.Dn (releases per decade) or even x.Cn (releases per century)? :-)
My brain prefers that I don't use long version numbers. Except when the version number is long because of some date (e.g. to indicate freshness of release). But why torture ourselves with a date that we need several seconds to parse in our head?
So I'll stick with 0.01, 0.02, 0.03, ... for now.
It's a date? I like dates for distro releases because it makes it easy to tell at a glance how current it is. YYYY.MM (arch's scheme) is pretty much perfect. But for other software I don't care so much, and I don't think it makes sense. I prefer API.Feature.Bugfix style version strings... or if it makes no sense to have that many numbers just version.bugfix for simple projects.
BalasHapusI'd also like to note that I don't think versions are numbers they are strings. This comes from the fact that sometimes they are dates like this, Other times they are Multipart like the Linux Kernel. And even when they're like 0.20 which is not how you'd ever display a number... it can jump to 1.00 on a whim.
The point to using 6 digits is that it's a multiple of 3, so it round-trips cleanly through 2-dotted versioning in the same way that Perl's versions do.
BalasHapusAlso, always using the same number of digits means there are fewer ways your version numbers might trip up parsers (CPAN, some OS distribution packaging tools, etc.)
@Hans:
BalasHapusThe RJBS scheme is 7 digits, not 6 digits.
Why do we need this so-called "round-trip" process? If you want something like Perl version scheme (xx.yy.zz), why don't use *exactly* the Perl version scheme?
And please tell me a CPAN dist/metadata parser or some OS distribution packaging tool that can't handle x.yy but can handle xx.yy.zz.