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 <hvr@gnu.org> wrote:
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