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

[Duncan Coutts]

On Wed, 2009-02-11 at 14:02 -0800, Corey O'Connor wrote:
> 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.

Right yes. Using a versioning scheme that relates to the API is a good
idea for libraries.

As Wolfgang mentioned, you may choose to follow the common package
versioning policy.

http://haskell.org/haskellwiki/Package_versioning_policy

We are planning to develop tool support for this. To let packages
explicitly opt-in and then we can hold such packages to their promise.
We can also advise authors about what form of version constraints they
should use for dependencies on packages that follow the PVP.

That said, there are still areas where date-based is fine. For example
the platform meta-package will be date based but also follow the PVP.

Duncan