Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide guidance on non-enumerated changes #56

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Provide guidance on non-enumerated changes #56

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion v1.1/pvp-specification.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -66,7 +66,7 @@ old *C*. Note that modifying imports or depending on a newer version of another
package may cause extra non-orphan instances to be exported and thus force a
minor version change.

1. *Other changes*. Otherwise, e.g. if change consist only of corrected
1. *Last-component changes*. Otherwise, e.g. if change consist only of corrected
documentation, non-visible change to allow different dependency range etc.
*A.B.C* **MAY** remain the same (other version components may change).

Expand Down Expand Up @@ -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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


Special situations
------------------

Expand Down