I agree that creating a new class or data type and supplying instances for it fits within the spirit of what the PVP allows in a minor revision, and should probably be clarified as we slowly try to etch a more accurate notion of what it means to be 'safe' in PVP terms.

w.r.t. having upper bounds at all, I think that belongs in a separate discussion.

For the record, you can put me down as +1 on this proposal in spirit.

There may be some quibbling I'd take with the language though for the case where you have a package with classes and a package that has orphans for those classes for a package that was too burdensome to add as a dependency for the base package, both under the control of the same maintainer. (Mutatis mutandis for data types) 

An example would be vector-instances. As I control both it, and most of the packages it makes orphans for, I'm simply constraining myself from not releasing versions of those packages with conflicting instances unless I bump them out of bounds.

I'd like to find a way to spell this out in clearer PVP'ese, but it is the way in which I'm most likely to be PVP non-compliant in the future.


On Wed, Feb 26, 2014 at 12:28 PM, Leon Smith <leon.p.smith@gmail.com> wrote:
I feel indifferent on this proposal.

I certainly think the PVP is wrong in the case when a library both adds a newtype or data type declaration and then adds an instance for it,  as it's impossible to break downstream dependencies in this way.   So I've been ignoring the strict letter of the PVP in this particular case,  although I'd argue that I'm still following the spirit of the PVP.    So whether or not this change is adopted,  I do think this point should be clarified.

My opinion on orphaned instances is that they should (almost always) be avoided in hackage-released libraries,  but that they are mostly harmless in executables,  whether hackage-released or not.   So under these assumptions, it's still possible to break something;  the question in my mind is whether or not it would be more work to tighten up dependencies after the fact (under the optimistic assumption that things usually won't break) or loosen things up.  Given that I'm not, at the moment, a fan of upper bounds at all,  I don't feel like this tradeoff impacts me much.  (Although obviously I'm coming down on the side of the optimistic assumption.)  But I do think it's important to have a good semantics for the PVP.

(And incidentally,  once (if?) we start adjusting version ranges without updating the version of the package,  then I will adopt upper bounds,  and I also feel that this issue would become mostly moot anyway.)

I also second Christian's comment that we really do need a more coherent story on orphaned instances,  as avoiding them really does put a damper on modularity. 

Best,
Leon


On Wed, Feb 26, 2014 at 11:01 AM, Mario Blažević <mblazevic@stilo.com> wrote:
On 14-02-26 07:37 AM, Johan Tibell wrote:
...


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./



+1, except I'd add the following ammendment:

In the interim period (for a year or so after the PVP change), the library maintainers that wish to take advantage of the change (i.e., add a new instance while incrementing only the minor package version) should check if any of the packages depending on their libraries contain clashing orphan instances. If so, they need to try to contact the depending package maintainers and get them to tighten the dependency bounds before the minor release. After the interim period is over, the responsibility falls onto the maintainers of the depending packages.

        Also, we should consider reserving the third component of the version for instance additions, and relegating function and type additions to lower components.



_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries