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