Corey O'Connor wrote:
Part of the reason they seem awkward to me is that I expect the difference between version numbers to indicate something about what has changed between the two versions. This only ends up being a heuristic but a useful one. Date based version numbers don't communicate much beyond, well, the date the release was built on unless annotations are added in addition to the date. Still, they don't read as nicely as X.Y.Z scheme version numbers.
Delimited date-based versions (YYYY.MM.DD[.X.Y.Z]) work better for specifying ranges. Though there is still the problem of correlating "version" into "feature set" or "api", which is true of any versioning scheme to varying degrees.
For projects which are released very frequently (i.e. on the order of daily) or very infrequently (e.g. semiannually, annually) then date-based releases can make sense. However, the releases do need to be quite regular on either of those time scales. This style is also appropriate for projects which exist in-time with our non-code world.
Often though, projects see sporadic flurries of improvements and so something that's been languishing for months can quickly make a couple bugfix releases followed by a backwards-incompatible rewrite in the same week, only to languish for a while afterwards. With this sort of release pattern, date-based versions make no sense whatsoever since the calendar makes rather arbitrary cliffs in the topology.
For most projects the Major.Minor.Bug style seems to work better, but I have seen projects where the YYYY.MM.DD style is more appropriate.
-- Live well, ~wren _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
