Question about the PVP regarding changing A.B when no entities are removed/changed
Hello all, 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: but the new C *must* be greater than the old C As an example, I (mistakenly) released generic-deriving-1.7.0 https://hackage.haskell.org/package/generic-deriving-1.7.0 after having added one function to it, bumping it from 1.6.3. If my interpretation of the PVP is correct, this change didn't follow the PVP only because I did not increase the C. Had I named it 1.7.4, it would have followed the PVP. (Oddly enough, 0.5.4 would have followed the PVP too!) 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? Thanks, Pedro
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
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
On Thu, Nov 06, 2014 at 11:06:44AM +0000, José Pedro Magalhães wrote:
As an example, I (mistakenly) released generic-deriving-1.7.0 https://hackage.haskell.org/package/generic-deriving-1.7.0 after having added one function to it, bumping it from 1.6.3. If my interpretation of the PVP is correct, this change didn't follow the PVP only because I did not increase the C. Had I named it 1.7.4, it would have followed the PVP. (Oddly enough, 0.5.4 would have followed the PVP too!)
The intention was to specify the minimum new version; you can always use a larger version than that if you want. It may well be sloppily worded, though (and if it allows version number to go down then it definitely is :-) ). Thanks Ian
On Fri, 7 Nov 2014, Ian Lynagh wrote:
The intention was to specify the minimum new version; you can always use a larger version than that if you want. It may well be sloppily worded, though (and if it allows version number to go down then it definitely is :-) ).
In principle it is ok to release a lower version later. E.g. you might maintain bugfix releases of two major versions.
On Fri, Nov 7, 2014 at 1:14 AM, Henning Thielemann
On Fri, 7 Nov 2014, Ian Lynagh wrote:
The intention was to specify the minimum new version; you can always use a larger version than that if you want. It may well be sloppily worded, though (and if it allows version number to go down then it definitely is :-) ).
In principle it is ok to release a lower version later. E.g. you might maintain bugfix releases of two major versions.
It seems logical to me that the PVP compares code based on version numbers, not moment of release. So if you release a bugfix based on 0.5 (with 0.6 already out) it would compare the API in your bugfix to 0.5, not 0.6. If the API of the bugfix doesn't change compared to 0.5, releasing as 0.5.0.1 is fine. Erik
Definitely. I have bug-fix branches where I slip critical fixes into older major versions that can't be used by some users, due to dependency changes, and routinely release them. On Thu, Nov 6, 2014 at 7:14 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Fri, 7 Nov 2014, Ian Lynagh wrote:
The intention was to specify the minimum new version; you can always use
a larger version than that if you want. It may well be sloppily worded, though (and if it allows version number to go down then it definitely is :-) ).
In principle it is ok to release a lower version later. E.g. you might maintain bugfix releases of two major versions.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
participants (8)
-
Adam Bergmark -
Edward Kmett -
Erik Hesselink -
Gregory Collins -
Henning Thielemann -
Herbert Valerio Riedel -
Ian Lynagh -
José Pedro Magalhães