[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

[Gershom Bazerman]

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