I think it would be bad to disallow a higher bumps than strictly necessary.
Quoting Sebas [1]: Don’t hide big impact changes behind minor bumps. Some
changes are major but don’t change the API, be careful with those. Silently
changing a network request timeout to a tenth of it’s original value in a
minor upgrade might break the user’s network stack. Fixing an encoding bug
that has been in the package for years? Chances are someone assumed this
was intended and now has a double encoding bug. Be explicit.
[1] http://fvisser.nl/post/2013/may/28/towards-a-better-haskell-package.html
- Adam
On Thu, Nov 6, 2014 at 12:23 PM, Herbert Valerio Riedel
On 2014-11-06 at 12:06:44 +0100, José Pedro Magalhães wrote:
The PVP https://www.haskell.org/haskellwiki/Package_versioning_policy seems to allow changing the A.B version numbers in a package even when no entities are removed/changed; the phrasing is (my emphasis):
if only new bindings, types, classes, non-orphan instances or modules (but see below) were added to the interface, then A.B *may* remain the same
However, it seems to require changing the C nonetheless:
It may seem so due, but it surely isn't the intent; the wording can probably be improved though.
[...]
I think this is a bit odd. Shouldn't we either:
1) Require that A.B remain the same when no entities are removed/changed, or 2) Only require the C to be greater if the A.B remained the same?
While 1) may be desirable, I don't think it's necessary to *force* it.
While I believe that 2) is matches the intent the current PVP wanted to express. So it may be a good idea to clarify that aspect by wording it more explicitly.
PS: IMO, the intent of the PVP is maybe easier to understand if you take on the point of view of declaring the version bounds when *using* a package following the PVP scheme, see also
https://www.haskell.org/haskellwiki/Import_modules_properly
Cheers, hvr _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries