On Wed, Feb 11, 2009 at 2:48 AM, Duncan Coutts 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

On Wed, Feb 11, 2009 at 10:20 PM, wren ng thornton wrote:

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.

I went with the Major.Minor.YYYY.MM.DD because I'm too lazy to increment bug-fix version numbers, and the code I have building the .cabal file already knows today's date. I guess that approach doesn't work too well if you're not machine generating your .cabal file, or if you expect more than one bug-fix release per day. -Antoine

On Wed, 2009-02-11 at 14:02 -0800, Corey O'Connor wrote:

On Wed, Feb 11, 2009 at 2:48 AM, Duncan Coutts 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