Bump dependency for base to next major version #39
Conversation
So we don't have to constantly be updating it. They are pretty good with keeping backwards-compatibility.
Well, that's just not true; I keep having to fixup all those optimistic |
|
Well, on the other side I keep having to fixup all those pessimistic bounds in various packages all the time... one has to fix the underlying problem (update to the new API) in any case and an overly pessimistic bound just adds to the total amount of work. |
|
There's no need to throw walls of text at me, I'm a Debian Developer maintaining about 100 packages give or take. My experience is that "the lagging way" as that document calls it is actually better in practise because it reduces overall long-term maintenance costs. Obviously it depends on the actual numbers you put in; my experience of |
|
I'm afraid we're going to have to agree to disagree then, as my experience with curating ~852 (out of 13k) packages on Hackage tells a different story... and even if the numbers were in your favour (which they actually can be for some corner-case situations of packages; however when taking into account the holistic nature of Hackage such smaller mistakes add up to the point where the seemingly small risk builds up into a significant large risk for every user of Hackage), it'd still be irresponsible to operate as you suggest as you'd effectively open the door to silent failures where the compiler wouldn't detect the API incompatibility. I'm afraid I'm going to have to throw yet another wall of text at you: https://pvp.haskell.org/faq/#upper-bounds PS: This month alone we had more revisions (~1000) performed than actual releases (~890) were uploaded to Hackage to fix mostly those naive "base < 5" assumptions being broken by one reason or another... |
|
How does a human detect an API incompatibility if a compiler doesn't detect it? Are you saying you manually read through the documentation (and source code for the cases where the documentation doesn't exist) to figure out the behavioural contracts for all the API methods of all 852 packages you curate? I think it's overexaggerating to call this "irresponsible", life involves taking negligible risks all the time. To put it another way, extending the version constraint to only But for sure feel free to close this PR if you disagree with the general principle. |
We're already taking risks even when following the PVP scheme (which nobody claims to be perfect; but it's the best tool we have so far); the point is to make those risks as small as possible and not to buy into the nirvana fallacy that since we cannot achieve perfection we shouldn't even try... so I stand by this: it is irresponsible if you care about correctness as you're effectively declaring defeat without even having tried. |
We have a finite amount of time resources to try to attain perfection in different areas of life. Some are more or less important than others. If we spend too much effort trying to attain perfection in the area of package metadata, we have less time for other things. IMHO it is irresponsible not to take risks based on these types of judgements. Of course in this case we judge differently based on our different experiences. |
Thanks for linking that, your position makes more sense with this in mind. It's not that obvious this is what everyone should be doing (or is doing) though. For example in the cabal users' guide it's only mentioned twice as a recommendation. By contrast the Rust ecosystem makes a pretty big deal out of semver especially in the Cargo documentation and it's hard to avoid comments about that nearly everywhere you look. |
So we don't have to constantly be updating it. They are pretty good with keeping backwards-compatibility.
Tested with base 4.11 and cabal 2.2.