Provide guidance on non-enumerated changes #56
Conversation
As inspired by #55 this PR does two things. First it changes "other changes" to "last-component changes" to disambiguate that this only covers other changes which are "extremely minor". Second, it adds a new clause for "non-enumerated changes" as an umbrella clause to handle any cases not explicitly enumerated elsewhere with the guidance that any change which would cause a package depending on the versioned package to fail to compile must be considered breaking. This clause then can cover new features introduced by GHC as general guidance without the PVP needing to be specifically updated immediately to cover them. (Though as time goes on, we may of course add more enumerated changes from new GHC features to the explicit enumerations of breaking and non-breaking changes).
|
-1
TLDR: how to figure out if you broke API: Compile all your reverse dependencies. |
|
The text of the proposed change makes no mention of GHC or an implementation. The above comment does not appear to be pertinent to the text of the proposed change, but arguing against something else entirely -- what, precisely, I don't know. |
Then it absolutely says nothing, because "would fail to compile" is entirely undefined and gives no value for the end user. |
|
The intention is that the guidance is considered with regards to the specified behavior of the new features. |
| @@ -100,6 +100,10 @@ name is taken from another package (e.g. when `network-bytestring` was merged | |||
| into `network`) or is quite general (`Data.Set` or something similar) then the | |||
| version increase **SHOULD** be major. | |||
|
|
|||
| 1. *Non-enumerated changes*. As the Haskell language evolves, new features may be introduced (e.g. rewrite rules) | |||
| which are not explicitly covered in the above rules. In such cases, in keeping with the spirit of the PVP, any changes not | |||
| enumerated above which would cause a package depending on the versioned package to fail to compile **MUST** be considered breaking. | |||
There was a problem hiding this comment.
Thinking about this a bit more, I'm not sure this is quite right. As it stands, exporting new names is a "non-breaking change", but this can cause downstream packages to not compile if they don't use explicit import lists. I think perhaps the statement we want is "unavoidably cause a downstream package to fail to compile"? I'm not sure.
There was a problem hiding this comment.
Hrm. I think that the export of names is a sort of exception carved out on a one-off basis after a bunch of discussion (and it was controversial). This clause isn't supposed to describe anything explicitly enumerated -- its the default policy for stuff that is not otherwise covered, and there I think its better to be on the safe side, allowing for exceptions to be made only after discussion of the trade-offs.
As inspired by #55 this PR does two things. First it changes "other changes" to "last-component changes" to disambiguate that this only covers other changes which are "extremely minor". Second, it adds a new clause for "non-enumerated changes" as an umbrella clause to handle any cases not explicitly enumerated elsewhere with the guidance that any change which would cause a package depending on the versioned package to fail to compile must be considered breaking.
This clause then can cover new features introduced by GHC as general guidance without the PVP needing to be specifically updated immediately to cover them. (Though as time goes on, we may of course add more enumerated changes from new GHC features to the explicit enumerations of breaking and non-breaking changes).