Another API stability plea
Ivan Lazar Miljenovic
ivan.miljenovic at gmail.com
Mon Aug 23 01:14:35 EDT 2010
On 23 August 2010 13:28, Alexander Dunlap <alexander.dunlap at gmail.com> wrote:
> 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 at gmail.com
IvanMiljenovic.wordpress.com
More information about the Libraries
mailing list