Hi, I tend to agree to this proposal, but I would like to encourage developers/researchers to invent something like named instances (or dictionaries), that are not transitively reexported and could coexist with current instances. (These would allow several, differently named, instances for the same type and class combination.) Non-orphaned instances are simply a too heavy burden for modularization! Nobody, who invents a shiny new class, supplies instances for all the base types and conversely, nobody, who defines a new type, also supports all our shiny classes in the base package. So many (though minor) package updates are required to add missing instances and the problem becomes more difficult for classes and types that are not in base. Cheers Christian Am 26.02.2014 13:37, schrieb Johan Tibell:
Hi all,
(This email is about trying to improve the PVP. If you think the PVP is a bad idea to begin with, please discuss that in a separate email thread.)
The PVP [1] states that
A.B is known as the major version number, and C the minor version number. When a package is updated, the following rules govern how the version number must change relative to the previous version:
* If any entity was removed, or the types of any entities or the definitions of datatypes or classes were changed, or instances were added or removed, then the new A.B must be greater than the previous A.B. Note that modifying imports or depending on a newer version of another package may cause extra instances to be exported and thus force a major version change.
* Otherwise, if only new bindings, types, classes or modules (but see below) were added to the interface, then A.B may remain the same but the new C must be greater than the old C.
* Otherwise, A.B.C may remain the same (other version components may change).
Bumping the major version number often introduce a number of downstream changes, as package author need to loosen dependency constraints to allow the new package version to be used. This creates quite a bit of work for maintainers.
A particular onerous requirement is to have to bump the major version whenever you add a new instance. In spirit adding a new instances feels like adding a new function, like making an extension to the API, something ought to not break clients who use qualified imports and/or explicit import lists. For this reason and because of the cost to downstream maintainers, I've sometimes avoided bumping the major version in the past when adding a new instance.
However, introducing a new instance can only break other packages if those packages define orphan instance. Here's my reasoning:
1. Assume there are no orphan instances. 2. Package D defines a data type and package C defines a type class (it's possible that D=C.) 3. An instance can only be added by either D or C. 4. D and C cannot both depend on each other, so both cannot add the same instance. 5. Another package O cannot add an instance (remember that orphans are disallowed). 6. Since O cannot define an instance, there cannot be any conflicts in O if D or C (whichever depends on the other) adds an instance.
If this is true, we could change the first two PVP rules to (differences in /italics/):
* If any entity was removed, or the types of any entities or the definitions of datatypes or classes were changed, or /orphan/ instances were added or /any instances were/ removed, then the new A.B must be greater than the previous A.B. Note that modifying imports or depending on a newer version of another package may cause extra instances to be exported and thus force a major version change.
* Otherwise, 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 but the new C must be greater than the old C.
and add the following clarifying sentence:
/If a package defines an orphan instance, it must depend on the minor version of the packages that define the data type and the type class to be backwards compatible. For example, build-depends: mypkg >= 2.1.1 && < 2.1.2./
I believe this would result in less work for maintainers.
1. http://www.haskell.org/haskellwiki/Package_versioning_policy
Discussion period: 3 weeks.
-- Johan
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries