On Tue, Feb 25, 2014 at 6:38 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:
This thread is kinda missing an important point.
Namely that on hackage now, the admins and trustees have the power to edit the cabal files to fix broken constraints. (As do maintainers of their own packages)
Whether relaxing incorrectly conservative or over strengthening overly lax constraints, this now doesn't require a rerelease to "fix". There are valid reasons of provinence for why that might not make sense in all case
Unless I'm missing the point, doesn't that solve most of the matter? -carter
The question would still remain: who's responsible for making those changes, and what is the default position for the version bounds? We could default to leaving version bounds off, and add them after the fact as necessary. This would reduce developer and Hackage maintainer overhead, but some users may get the "scary" error messages[1]. Or we could default to the PVP approach, and then increase the work on developers/maintainers, with the flip side that (1) users will never get the "scary" error messages, and (2) until developers/maintainers make the change, users may be blocked from even attempting to compile packages together. There's also the issue that, currently, Hackage2 has turned off developer abilities to change version bounds, so all of the version tweaking onus would fall to admins and trustees. Overall, I don't see this as a big improvement over the PVP status quo. It's not any harder for me to upload version 1.0.2.1 of a package with a tweaked version bound than to go to the Hackage web interface and manually edit version 1.0.2's cabal file. What I see the editing feature as very useful for is if we want to add upper bounds after the fact. Michael [1] Which I still think have value, since they are far more informative to a package author.