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

[Corey O'Connor]

On Wed, Feb 11, 2009 at 2:48 AM, Duncan Coutts
<duncan.coutts at worc.ox.ac.uk> wrote:
> On Tue, 2009-02-10 at 10:21 -0800, Corey O'Connor wrote:
>> I released a new version of data-spacepart that resolved some of the
>> issues with the previous release. One issue I had was the previous
>> release used the version numbering scheme I use at work:
>> [date].[release] Which does not appear to work as well as the
>> traditional X.Y.Z release numbering scheme with Cabal.
>
> I'm not sure I understand. Is there something in Cabal or Hackage that
> makes date-based numbering schemes not work well?

I think version number schemes of the X.Y.Z form are easier to work
with when defining cabal depends constraints. A user of the library
can use the constrain "data-spacepart == 0.1.*" to specifying a
dependency on any 0.1 release. For date-based version numbers what
would the constraint be? "data-spacepart == 20090211.*" maybe? Or
constrain to a range of dates? Both seem awkward to me.

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.

The way I read changes in version numbers for a scheme using the
format X.Y.Z is:
 * A change in Z indicates bug fixes only
 * A change in Y indicates the interface has changed but not in an
incompatible way. For instance, maybe a new method was added.
 * A change in X indicates the interface has changed in a way that
could be incompatible with software that depended on a previous
version of the library.

I don't know of a mapping that can be applied to date based version
numbers that is as rigorous.

> Yeah, there's not a lot you can do except make the number higher. The
> problem is not just hackage, it's all the previous releases in the wild.
> All the tools assume the normal ordering on version numbers. Not just
> the Cabal/Hackage tools but the native distro tools too.

Hm aye. I guess this explains all the packages with 3000.X (and so on)
version numbers.

Cheers,
Corey O'Connor