PVP proposal: don't require major version bump when adding non-orphan instances

Wed Feb 26 19:32:04 UTC 2014

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 at 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 at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140226/c91adb69/attachment.html>