* Philippe Bruhat (BooK) <philippe.bru...@free.fr> [2012-06-01 01:25]: > On Thu, May 31, 2012 at 08:12:37PM +0100, David Cantrell wrote: > > On Thu, May 31, 2012 at 10:49:36AM -0700, Jarrod Overson wrote: > > > You lose the version's value as an actual number, but you gain > > > more standard readability as to what the version means, which is > > > something that I consider more valuable. > > > > You lose that the moment someone decides to rename Linux 2.6.bignum > > to 3.0 for no good reason. So really, no matter what the ideal, in > > practice it doesn't mean a damned thing. > > Which is why some people have moved to integer versions, based on the > date, with extra digits tacked at the end to allow for multiple > releases on the same day: a package released today would have the > version 2012060101. (to be read as 2012-06-01 release 01).
Which is why File::Slurp is now version 9999.19 on the CPAN. If you’re going to use date-based versions I suggest V.YYmmNN as the format, with V being some arbitrary major version number. So e.g. the first release cut during May 2012 would be 2.120501. (I omit the day since a limit of 99 releases a month is reasonable but lengthening the version number by another 2 digits would not be.) Then you can change your mind about the versioning scheme without having to contend with 9999999999.xxxxxx (or else abandoning the namespace so that you get to start over). Simply bump the major version to switch to another convention. You lose the easy intuitiveness of plain date-based versions, of course, and thus a major attraction, but you do retain the same information they provide (save for the exact age in days, which is meaninglessly precise in the grand scheme of things). Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
