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

[wren ng thornton]

On 8/22/12 9:18 AM, Leon Smith wrote:
> I think we actually agree more than we disagree;  I do think distinguishing
> hard and soft upper bounds (no matter what they are called)  would help,
>   and I'm just trying to justify them to some of the more dismissive
> attitudes towards the idea

Hopefully. Though you suggested conflating the hard/soft distinction and 
the reactive/proactive distinction, and I can't see how that would even 
make sense. The former is a matter of ontology (i.e., categorization of 
what things can/do/should exist), whereas the latter is a matter of 
policy (i.e., how people can/do/should behave). Clearly there's some 
relation between the two, but the distinctions are talking about 
completely different topics.


> The only thing I think we (might) disagree on is the relative importance of
> distinguishing hard and soft bounds versus being able to change bounds
> easily after the fact (and *without* changing the version number associated
> with the package.)
>
> And on that count,  given the choice,  I pick being able to change bounds
> after the fact, hands down.

Well sure, just updating Cabal to say it has soft upper bounds doesn't 
mean much unless they're actually overridable somehow ;)


I'm still dubious of being able to override hard bounds with a 
commandline flag. If the hard bound is valid then when you pass the flag 
to ignore the bound either (a) the code won't compile ---so the flag 
doesn't help any---, or (b) the code will compile in a way known to be 
silently wrong/buggy ---so the flag is evil.  Circumventing a (valid) 
hard bound is going to require altering the code, so what benefit is 
there in avoiding to alter the .cabal file at the same time?

The only case I can conceive of it being helpful to circumvent a hard 
bound is if, in fact, the statement of the hard bound is incorrect. But, 
if that's the case, it's a bug; and surely correcting that bug should 
warrant nudging the fourth version number, ne? Also, this situation 
doesn't strike me as being common enough to warrant the effort of 
implementation. If it came for free from whatever work it takes to 
implement soft bounds (which must necessarily be overridable), I 
wouldn't really care. But if eliminating this burden would help in 
getting soft bounds implemented, then I see no downside to axing it.

-- 
Live well,
~wren