On 23 August 2010 13:28, Alexander Dunlap
If that happens, is the PVP even needed anymore?
How else do you decide what the new version number should be? How about determining as a programmer what the difference between two versions of a package are (or at least how great those differences should be)?
If Hackage automatically checks when packages break, couldn't it automatically determine upper bounds?
This relies on every package being buildable on Hackage, which assumes appropriate C libs, environment, etc. It also means that Hackage is editing the .cabal file (or equivalent) to specify said dependencies. Finally, consider what happens with downstream packages for Linux distributions, etc.: how do they choose what the range of dependencies is if Hackage will some day magically change an upper bound without the distribution packages being aware of this as they're already built/packaged.
Then we wouldn't need the conservative upper-bound settings.
A better solution to this IMHO is one that Duncan has talked about, where rather than having to upload a new point-release when a dependency has a new compatible major release, you can just edit the .cabal file in effect to loosen the upper bound. Whilst this still has the same "magic change" problem as above, at least this way there is _an_ upper bound to start with that should work.
Of course, it seems like a fairly ambitious proposal to do all this checking automatically.
I'm sure patches are accepted ;-) -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com