hackage version scheme survey
It's not good to specify open version ranges in cabal build-depends like foo >= 1.1 because the foo maintainer will eventually release 2.0, containing API-breaking changes, and the build will fail. If you depend on foo 1.1, you can specify == 1.*, no problem. But if you depend on a package that uses a version scheme like 1.2.3 or 1.2.3.4, it's not clear (at least to me) where the major/minor division is. I did a survey of version schemes in 'cabal list': 484 packages use a.b. 630 packages use a.b.c. 180 packages use a.b.c.d. The rest: two packages use just one field for their versions; one uses five; one uses six. Maybe most of the a.b people are thinking major.minor, and most of the a.b.c people are thinking breaking.feature.implementation like the "rational" RubyGems scheme described in http://rubygems.org/read/chapter/7#page24 , but I don't know. It makes it hard to describe dependencies. Will there be a standard versioning scheme sometime?
2009/5/24
Maybe most of the a.b people are thinking major.minor, and most of the a.b.c people are thinking breaking.feature.implementation like the "rational" RubyGems scheme described in http://rubygems.org/read/chapter/7#page24 , but I don't know. It makes it hard to describe dependencies. Will there be a standard versioning scheme sometime?
We have one already: http://www.haskell.org/haskellwiki/Package_versioning_policy David
brian:
Maybe most of the a.b people are thinking major.minor, and most of the a.b.c people are thinking breaking.feature.implementation like the "rational" RubyGems scheme described in http://rubygems.org/read/chapter/7#page24 , but I don't know. It makes it hard to describe dependencies. Will there be a standard versioning scheme sometime?
On Saturday, 23.05.09 at 17:26, Don Stewart wrote:
That helps a lot. I should have found that. But putting the policy on a web page doesn't seem to be working; there are a lot of non-compliant packages. I guess I'm surprised thah 'cabal check' doesn't complain about it and HDB doesn't reject them.
brian@lorf.org wrote:
On Saturday, 23.05.09 at 17:26, Don Stewart wrote:
That helps a lot. I should have found that. But putting the policy on a web page doesn't seem to be working; there are a lot of non-compliant packages. I guess I'm surprised thah 'cabal check' doesn't complain about it and HDB doesn't reject them.
I hear they're looking for someone to write a program to check for API changes in order to detect and enforce the policy :) Care to help? -- Live well, ~wren
On Sat, 2009-05-23 at 19:57 -0500, brian@lorf.org wrote:
On Saturday, 23.05.09 at 17:26, Don Stewart wrote:
That helps a lot. I should have found that. But putting the policy on a web page doesn't seem to be working; there are a lot of non-compliant packages. I guess I'm surprised thah 'cabal check' doesn't complain about it and HDB doesn't reject them.
We cannot force maintainers to follow the PVP, however we do have a plan to encourage adoption. The key is to get maintainers to opt-in. For packages that opt-in we will enforce it. Following the PVP is extra work for a maintainer so there need to be two sides to the bargain. The benefit to maintainers that we can enforce that all newly uploaded hackage packages that depend on their PVP-following package do actually specify an upper version bound. This benefits the maintainer because it lets them release new versions knowing that they are not breaking dependent packages. The bargain on the other side is that it's a benefit to you as a package author if you can rely on the proper versioning of the packages you depend on. In return however you must actually make proper use of that by specifying appropriate upper bounds (and the tools should be able to give helpful suggestions). However, like most of our grand plans, there's nobody actually working on implementing them at the moment. The key part of this plan is the PVP checker tool. Duncan
participants (6)
-
Brian Lewis -
brian＠lorf.org
-
David Waern -
Don Stewart -
Duncan Coutts -
wren ng thornton