[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


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

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! :-)


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