[Haskell-cafe] Changing version numbering schemes for HackageDB packages?

[wren ng thornton]

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