[Haskell-cafe] Changing version numbering schemes for HackageDB
wren ng thornton
wren at freegeek.org
Wed Feb 11 23:20:48 EST 2009
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.
More information about the Haskell-Cafe