Re: [Haskell-cafe] Changing version numbering schemes for HackageDB packages?
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. As part of the new release I changed the version numbering scheme. An *obviously* bad idea if I thought it through. Any [date].[release] style version number is greater than a X.Y.Z version number until X gets rather large. So what to do? Continue using the [date].[release] version numbering scheme? Or is there a way to coax HackageDB to ignore the old release? Use a (slightly) different package name? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Changing version numbering schemes for HackageDB packages?
Am Mittwoch, 11. Februar 2009 23:02 schrieb Corey O'Connor: 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. Note that Haskell’s package versioning policy [1] assigns your meaning of Z to the 4th component of the version, your meaning of Y to the 3rd and your meaning of X to the pair of the 1st and the 2nd component. Best wishes, Wolfgang [1] http://haskell.org/haskellwiki/Package_versioning_policy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Changing version numbering schemes for HackageDB packages?
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.cou...@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Changing version numbering schemes for HackageDB packages?
On Thu, Feb 12, 2009 at 4:12 AM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: 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. Thanks for the documentation! That's helpful. I'll change the libraries I maintain to follow this policy. None of them would work well for a date-based scheme. Thanks again, Corey O'Connor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Changing version numbering schemes for HackageDB packages?
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? As part of the new release I changed the version numbering scheme. An *obviously* bad idea if I thought it through. Any [date].[release] style version number is greater than a X.Y.Z version number until X gets rather large. So what to do? Continue using the [date].[release] version numbering scheme? Or is there a way to coax HackageDB to ignore the old release? 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. People have suggested epochs, but it turns out this doesn't make the situation any better, as one can never get rid of having to specify the epoch (eg 1:0.1.1). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Changing version numbering schemes for HackageDB packages?
On Wed, Feb 11, 2009 at 2:48 AM, Duncan Coutts duncan.cou...@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Changing version numbering schemes for HackageDB packages?
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 (.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 .MM.DD style is more appropriate. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Changing version numbering schemes for HackageDB packages?
On Wed, Feb 11, 2009 at 10:20 PM, wren ng thornton w...@freegeek.org 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 .MM.DD style is more appropriate. I went with the Major.Minor..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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Changing version numbering schemes for HackageDB packages?
* Corey O'Connor coreyocon...@gmail.com [2009-02-10 10:21:54-0800] 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. As part of the new release I changed the version numbering scheme. An *obviously* bad idea if I thought it through. Any [date].[release] style version number is greater than a X.Y.Z version number until X gets rather large. So what to do? Continue using the [date].[release] version numbering scheme? Or is there a way to coax HackageDB to ignore the old release? From haxr changelog: Sun Feb 11 11:43:15 EET 2007 bj...@bringert.net * Changed haxr version number to 3000.0.0 to avoid ordering problems with old date-based version numbers. -- Roman I. Cheplyaka :: http://ro-che.info/ Don't let school get in the way of your education. - Mark Twain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
