IIRC, the rules (for libraries at least) are (correct me if I'm wrong): - When you introduce a new entity in the public interface, such as a new typeclass, a new exported type, a new exported function, etc., you should bump the *second* number. This is because such introductions are only breaking changes when the consumer imports your modules unqualified and completely (i.e. `import The.Module`, not `import qualified The.Module as TM` nor `import The.Module (foo, bar)`). Importing your module "safely" will not break anything because the previous entities are still there, and the new ones simply won't be imported, so they cannot cause any clashes. - When you change the signature of an existing public entity, you should bump the first number, because this is a potential breaking change even with "safe" imports. - When you remove an existing public entity, or an entire module, or rename either, you should also bump the first number, for the same reasons. And then on the consumer side, this means you can decide to either fix your dependencies to just the first version number and import everything "safely" (qualified / per identifier), or to fix them to 2-part version numbers and use "dangerous" imports.
From my experience, however, this is neither watertight nor something everyone follows religiously, so in practice it isn't all that useful after all. Part of the problem is probably that there are no tools in widespread use that would block a release under a "wrong" version number, although I don't see any reasons why this should be technically impossible to do.
On Mon, Dec 15, 2014 at 08:42:48PM -0500, Zach Moazeni wrote:
Hello,
Forgive me if this is a frequently asked question, I've searched the web and can't find an answer. I originally sent this to the Beginners list and someone said this might get more responses here instead.
What is the history that led up to the PVP https://www.haskell.org/haskellwiki/Package_versioning_policy specifying two values as the major version?
I come from other tools that primarily use http://semver.org/ (or a variant) and I'm confused in what cases I should bump "A" but not "B" (or bump "B" but not "A")?
A concrete example: If I make backwards incompatible changes to a package whose latest version is 1.0.x, should the next version be 2.0.x or 1.1.x? What sorts of things should I consider for choosing 2.0 over 1.1 and vice versa?
Another question, by far most packages I have encountered either lead with a 0 or a 1 for "A". Does that have some bearing on the long term stability that package users should expect in the future?
Finally, if "1.0.x.." is meant to convey a level of long term support, does "B" get rarely used? Since "C" version bumps to include backwards compatible additions, and "D"+ for backwards compatible bug fixes. (I know "D" isn't technically a PVP category, I'm just relating it to the patch version of semver).
Thanks for your help!
-Zach
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Tobias Dammers - tobias@twokings.nl - 070-3457628 - www.twokings.nl Maandag t/m donderdag van 9.00 tot 17.30 Voor dringende vragen, mail naar support@twokings.nl