On 8/16/12 11:33 PM, wren ng thornton wrote:
[1] Parsec 2 vs 3, for a very long time
[2] mtl 1 vs 2, for a brief interim
[3] John Lato's iteratee <=0.3 vs >=0.4, for legacy code
...

I think this is a great point! As others have said, maintainers typically, but not always, know when their code is likely to break client libraries and software. But super-major numbers (i.e. the x of x.y) get bumped for other reasons, and sometimes sub-major (majorette?) numbers (i.e. the y of x.y) get bumped for massively breaking changes as well (which is in perfect accord with the PVP).

One other solution would be to introduce a new, optional (at least at first) field in cabal files -- perhaps named something like "api-version" or "api-epoch". This is just an integer, and it just gets bumped on massively breaking changes likely to force all client code to adapt. That way I can specify a traditional package lower bound with a real version number, and also specify (optionally, at least at first) an "upper bound" of an api-epoch. Most of my packages have never experienced an api-epoch event, and many likely won't ever. Most of their dependencies -- likewise.

At the cost of some extra (optional) annotations, this gives us a sort of compromise between the current, very painful, situation and the no-upper-bound situation where occasionally an epoch event breaks an enormous chunk of the ecosystem.

Cheers,
Gershom

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to