On RJBS's automatic version numbering scheme
Everytime I browse through CPAN recent uploads, and see versions of modules with RJBS's automatic numbering scheme, like 2.100920 or 1.091200 I tend to read it as 2.(noise) and 1.(more noise).
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 of that month, 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 - 20th
Or 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.
A programmer (mostly Perl 5 nowadays).
My CPAN ID: SHARYANTO. I'm sedusedan on perlmonks. My twitter is stevenharyanto (but I don't tweet much). Follow me on github: sharyanto.
This baffles me. Why does it need to be a system that requires several paragraphs to explain? I prefer simplicity: 0.1, 0.2, ..., 0.9, 1.0, 1.1, ..., 1.9, 2.0, 2.1, ...
These version numbers are short and easy to remember. A user can always look at the release date to see how old it is. Trying to encode all sorts of extra information into a version number is a recipe for confusion!
I don't like it either, which is why I wrote this.
@Carey: Well, whether or not we should encode date or other extra information into version number is beyond the scope of this article. It enters the realm of religion :-) But my point is that the date should be human friendly. RJBS's rationale of saving just one digit using YYDDD instead of YYMMDD is not really convincing for me.
Btw, now I am thinking that RJBS deliberately picks this for the publicity value :-) He's just too smart for this :-) No offence to RJBS.
The point is being able to do stateless releases. I.e. you don't have to look up your old version, or write down the new one somehere permanently.
My alternate version plugin keeps track of versions using Git tags. But RJBS's doesn't need that.
@Ævar: The release process still needs to check for previous releases for that day anyway.
Inherent in this system is a promise that you won't release a dist more than once a day. That's checked between the chair and the keyboard.
I don't like the idea of using the version number as a date indication. There's a few applications that haven't had a release in years but are still extremely stable (Nylon socksd, Apache's mod_rpaf, etc.), so the latest release date shouldn't matter to you necessarily.
There is a recommended way (in all of software world) to provide release date information of programs, that is the Change Log. That is where you're suppose to list those details. Why add it in the version? Just complexes things.
If a student tells me they are having problems with Padre, I can ask "which version?" and they would say "4.64" instead of "4.5679272905876166a878zkijwdalpha". That is also better than "the one released at January 12th, 2010."
Also, a version number already means something, universally. At least the difference between versions. It means what kind of update was this. For example, MySQL 5 vs. MySQL 6. You know it's damn sure to be important. Or App::cpanminus 4.56 vs. App::cpanminus 4.66.
The notion is that major version numbers are for core rewrites (see `ack` 2.0, for example) and such, minor versions are for important changes (Dancer 1.6x vs. Dancer 1.7x) and the others are incremental changes.
It helps the user identify how close the should read the changeset, if at all.
I personally like just using 0.01, 0.02, 0.03, etc. Simple, clean, readable.
@Ævar that's an angle I hadn't considered. I'd probably lean towards integer versions if that was a requirement, something like YYYYMMDDHH. I suppose at the end of the day, Steven is probably right--it's a religious issue--but it's still interesting to hear a possible reason for such a scheme.
Personally, I'm a fan of version numbers that are boring and incremental. As long as I can install a newer version in place of an older version of my modules, and I don't have to think too hard about their version number, I'm happy enough.
I use RJBS' AutoVersion numbers because they fit the job in hand and I haven't found anything that let's me be that lazy ;)
@SawyerX: You're right, that's another reason why I like short version numbers, pronouncability :-)
In RJBS's scheme the first part of the version number is the major version. I.e. $major.$date.