[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
Joachim Breitner
mail at joachim-breitner.de
Thu Aug 16 10:45:46 CEST 2012
Hi,
Am Mittwoch, den 15.08.2012, 12:38 -0700 schrieb Bryan O'Sullivan:
> I propose that the sense of the recommendation around upper bounds in
> the PVP be reversed: upper bounds should be specified only when there
> is a known problem with a new version of a depended-upon package.
as a Debian packager, I kinda like the tight upper bounds, as it allows
me to predict what packages will break when I upgrade package X. It is
only an approximation, but a safe one. If we would not have this, then I
would either
* upgrade X, upload to Debian, start rebuilding other stuff (this
is automated and happens on Debians build servers), notice a
break in package Y and then have to wait for Y’s upstream author
to fix it. All the while, Y and all its reverse dependencies
would not be installable. If this collides with a freeze, we’d
be in big trouble.
* upgrade X locally, rebuild everything manually and locally and
only if thinks work out nicely, upload the whole bunch. Would
work, but would be a huge amount of extra work.
(note that in Debian we have at most one version of each Haskell
package).
I think what we’d need is a more relaxed policy with modifying a
package’s meta data on hackage. What if hackage would allow uploading a
new package with the same version number, as long as it is identical up
to an extended version range? Then the first person who stumbles over an
upper bound that turned out to be too tight can just fix it and upload
the fixed package directly, without waiting for the author to react.
If modifying packages with the same version number is not nice (it does
break certain other invariants), we could make it acceptable behavior to
upload someone else’s package without asking provided
* one bumps the last (forth) component of the version
* one extends the version range to encompass a set of versions
that the uploader has just tested to work _without changes_
* no other change to the tarball is done.
This way, the common user of hackage (including us distro packagers)
will likely get a successful build if the build dependencies are
adhered, but new version will much quicker work everywhere, even when
original authors are temporarily slow to react.
More power to everyone! Be bold! :-)
Greetings,
Joachim
--
Joachim "nomeata" Breitner
mail at joachim-breitner.de | nomeata at debian.org | GPG: 0x4743206C
xmpp: nomeata at joachim-breitner.de | http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120816/fa030b6c/attachment.pgp>
More information about the Haskell-Cafe
mailing list