Johan Tibell | 26 Feb 13:37 2014
Picon

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

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.


Discussion period: 3 weeks.

-- Johan

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Henning Thielemann | 26 Feb 13:56 2014
Picon

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

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

As far as I remember we already discussed this:
    http://www.haskell.org/pipermail/libraries/2011-December/017337.html
Michael Snoyman | 26 Feb 14:14 2014

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




On Wed, Feb 26, 2014 at 2:56 PM, Henning Thielemann <schlepptop <at> henning-thielemann.de> wrote:
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.)

As far as I remember we already discussed this:
   http://www.haskell.org/pipermail/libraries/2011-December/017337.html



As last time, I'm +1 on this proposal. 
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Johan Tibell | 26 Feb 15:59 2014
Picon

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

On Wed, Feb 26, 2014 at 1:56 PM, Henning Thielemann <schlepptop <at> henning-thielemann.de> wrote:
As far as I remember we already discussed this:
   http://www.haskell.org/pipermail/libraries/2011-December/017337.html

Apparently I'm getting old and forgetful. :/

By looking at the last thread and this thread I think the following people support the proposal:

Johan Tibell
Michael Snoyman
Christian Maeder
Henning Thielemann

And the following people against:

Ganesh Sittampalam
Ivan Lazar Miljenovic
Erik Hesselink

There were also lots of discussion by other people and, as per the rule on mailing lists discussions, discussions that weared off in a bunch of directions*.

Some comments to help further discussions:
  • You can still write "orphan" instances by using a newtype, if the instance is only used internally. I did this in e.g. ekg which needed some aeson instances. It added a couple if line of code to the library as a whole.
  • You can still write orphan instances, you just need to have tighter version bounds.
  • There were some comments along the lines of "I prefer major version bumps to breakages." This doesn't introduce breakages, as long as people follow the updated PVP.
P.S. Other core library maintainers and I have already avoided bumping the major versions in several libraries, including containers and hashable, in the past, as I knew that would require more or less every package author to release a new version of their packages. In other words, we don't quite follow the PVP today and I don't think we should (i.e. we should change the PVP to match current practice.)

* This is probably what I eventually abandoned the discussion and it's something that has annoyed me about libraries <at> discussions for quite some time. We, as a community, need to get better at concentrate on the technical discussion at hand. We cannot redesign Haskell in every libraries proposal thread, as fun as that might be. The alternative would be to have less community input on these decisions -- which I think would be a shame -- as is common in other language communities.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Johan Tibell | 26 Feb 16:11 2014
Picon

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

On Wed, Feb 26, 2014 at 3:59 PM, Johan Tibell <johan.tibell <at> gmail.com> wrote:
By looking at the last thread and this thread I think the following people support the proposal:

Forgot:

Herbert Valerio Riedel

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
John Lato | 26 Feb 20:21 2014
Picon

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

+1 to this proposal in general, as well as updating the PVP to match current practice.

John

On Feb 26, 2014 6:59 AM, "Johan Tibell" <johan.tibell <at> gmail.com> wrote:
On Wed, Feb 26, 2014 at 1:56 PM, Henning Thielemann <schlepptop <at> henning-thielemann.de> wrote:
As far as I remember we already discussed this:
   http://www.haskell.org/pipermail/libraries/2011-December/017337.html

Apparently I'm getting old and forgetful. :/

By looking at the last thread and this thread I think the following people support the proposal:

Johan Tibell
Michael Snoyman
Christian Maeder
Henning Thielemann

And the following people against:

Ganesh Sittampalam
Ivan Lazar Miljenovic
Erik Hesselink

There were also lots of discussion by other people and, as per the rule on mailing lists discussions, discussions that weared off in a bunch of directions*.

Some comments to help further discussions:
  • You can still write "orphan" instances by using a newtype, if the instance is only used internally. I did this in e.g. ekg which needed some aeson instances. It added a couple if line of code to the library as a whole.
  • You can still write orphan instances, you just need to have tighter version bounds.
  • There were some comments along the lines of "I prefer major version bumps to breakages." This doesn't introduce breakages, as long as people follow the updated PVP.
P.S. Other core library maintainers and I have already avoided bumping the major versions in several libraries, including containers and hashable, in the past, as I knew that would require more or less every package author to release a new version of their packages. In other words, we don't quite follow the PVP today and I don't think we should (i.e. we should change the PVP to match current practice.)

* This is probably what I eventually abandoned the discussion and it's something that has annoyed me about libraries <at> discussions for quite some time. We, as a community, need to get better at concentrate on the technical discussion at hand. We cannot redesign Haskell in every libraries proposal thread, as fun as that might be. The alternative would be to have less community input on these decisions -- which I think would be a shame -- as is common in other language communities.


_______________________________________________
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
Ganesh Sittampalam | 27 Feb 00:28 2014
Picon

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

On 26/02/2014 14:59, Johan Tibell wrote:
> On Wed, Feb 26, 2014 at 1:56 PM, Henning Thielemann
> <schlepptop <at> henning-thielemann.de
> <mailto:schlepptop <at> henning-thielemann.de>> wrote:
> 
>     As far as I remember we already discussed this:
>      
>      http://www.haskell.org/__pipermail/libraries/2011-__December/017337.html
>     <http://www.haskell.org/pipermail/libraries/2011-December/017337.html>
> 
> 
> Apparently I'm getting old and forgetful. :/
> 
> By looking at the last thread and this thread I think the following
> people support the proposal:
> 
> Johan Tibell
> Michael Snoyman
> Christian Maeder
> Henning Thielemann
> 
> And the following people against:
> 
> Ganesh Sittampalam
> Ivan Lazar Miljenovic
> Erik Hesselink

I think my previous opposition was based on the fact that orphan
instances appeared to be ruled out altogether by the proposal then.

Given the statement in your new proposal "If a package defines an orphan
instance, it must depend on the minor version of the packages", I'm now
a +1.

Ganesh
Ivan Lazar Miljenovic | 27 Feb 00:47 2014
Picon

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

On 27 February 2014 10:28, Ganesh Sittampalam <ganesh <at> earth.li> wrote:
> On 26/02/2014 14:59, Johan Tibell wrote:
>> On Wed, Feb 26, 2014 at 1:56 PM, Henning Thielemann
>> <schlepptop <at> henning-thielemann.de
>> <mailto:schlepptop <at> henning-thielemann.de>> wrote:
>>
>>     As far as I remember we already discussed this:
>>
>>      http://www.haskell.org/__pipermail/libraries/2011-__December/017337.html
>>     <http://www.haskell.org/pipermail/libraries/2011-December/017337.html>
>>
>>
>> Apparently I'm getting old and forgetful. :/
>>
>> By looking at the last thread and this thread I think the following
>> people support the proposal:
>>
>> Johan Tibell
>> Michael Snoyman
>> Christian Maeder
>> Henning Thielemann
>>
>> And the following people against:
>>
>> Ganesh Sittampalam
>> Ivan Lazar Miljenovic
>> Erik Hesselink
>
> I think my previous opposition was based on the fact that orphan
> instances appeared to be ruled out altogether by the proposal then.
>
> Given the statement in your new proposal "If a package defines an orphan
> instance, it must depend on the minor version of the packages", I'm now
> a +1.

I think I was the same, so I'm now +1 as well.

--

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic <at> gmail.com
http://IvanMiljenovic.wordpress.com
Erik Hesselink | 27 Feb 01:05 2014
Picon

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

On Thu, Feb 27, 2014 at 12:47 AM, Ivan Lazar Miljenovic
<ivan.miljenovic <at> gmail.com> wrote:
> On 27 February 2014 10:28, Ganesh Sittampalam <ganesh <at> earth.li> wrote:
>> On 26/02/2014 14:59, Johan Tibell wrote:
>>> On Wed, Feb 26, 2014 at 1:56 PM, Henning Thielemann
>>> <schlepptop <at> henning-thielemann.de
>>> <mailto:schlepptop <at> henning-thielemann.de>> wrote:
>>>
>>>     As far as I remember we already discussed this:
>>>
>>>      http://www.haskell.org/__pipermail/libraries/2011-__December/017337.html
>>>     <http://www.haskell.org/pipermail/libraries/2011-December/017337.html>
>>>
>>>
>>> Apparently I'm getting old and forgetful. :/
>>>
>>> By looking at the last thread and this thread I think the following
>>> people support the proposal:
>>>
>>> Johan Tibell
>>> Michael Snoyman
>>> Christian Maeder
>>> Henning Thielemann
>>>
>>> And the following people against:
>>>
>>> Ganesh Sittampalam
>>> Ivan Lazar Miljenovic
>>> Erik Hesselink
>>
>> I think my previous opposition was based on the fact that orphan
>> instances appeared to be ruled out altogether by the proposal then.
>>
>> Given the statement in your new proposal "If a package defines an orphan
>> instance, it must depend on the minor version of the packages", I'm now
>> a +1.
>
> I think I was the same, so I'm now +1 as well.

I've also changed my mind, depending on a minor version (or going with
a newtype) seems good enough. I guess that's all the -1's...

Erik
Johan Tibell | 18 Mar 19:18 2014
Picon

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

The deadline have now passed. I think everyone who was against the prior proposal changed their mind as I clarified this proposal. I will make the changes to the PVP.


On Thu, Feb 27, 2014 at 1:05 AM, Erik Hesselink <hesselink <at> gmail.com> wrote:
On Thu, Feb 27, 2014 at 12:47 AM, Ivan Lazar Miljenovic
<ivan.miljenovic <at> gmail.com> wrote:
> On 27 February 2014 10:28, Ganesh Sittampalam <ganesh <at> earth.li> wrote:
>> On 26/02/2014 14:59, Johan Tibell wrote:
>>> On Wed, Feb 26, 2014 at 1:56 PM, Henning Thielemann
>>> <schlepptop <at> henning-thielemann.de
>>> <mailto:schlepptop <at> henning-thielemann.de>> wrote:
>>>
>>>     As far as I remember we already discussed this:
>>>
>>>      http://www.haskell.org/__pipermail/libraries/2011-__December/017337.html
>>>     <http://www.haskell.org/pipermail/libraries/2011-December/017337.html>
>>>
>>>
>>> Apparently I'm getting old and forgetful. :/
>>>
>>> By looking at the last thread and this thread I think the following
>>> people support the proposal:
>>>
>>> Johan Tibell
>>> Michael Snoyman
>>> Christian Maeder
>>> Henning Thielemann
>>>
>>> And the following people against:
>>>
>>> Ganesh Sittampalam
>>> Ivan Lazar Miljenovic
>>> Erik Hesselink
>>
>> I think my previous opposition was based on the fact that orphan
>> instances appeared to be ruled out altogether by the proposal then.
>>
>> Given the statement in your new proposal "If a package defines an orphan
>> instance, it must depend on the minor version of the packages", I'm now
>> a +1.
>
> I think I was the same, so I'm now +1 as well.

I've also changed my mind, depending on a minor version (or going with
a newtype) seems good enough. I guess that's all the -1's...

Erik
_______________________________________________
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
Christian Maeder | 26 Feb 14:19 2014
Picon

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

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 <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
Henning Thielemann | 26 Feb 19:14 2014
Picon

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

Am 26.02.2014 14:19, schrieb Christian Maeder:
> 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.)

I expressed the idea of programmable instance selection in the past:

http://www.haskell.org/pipermail/libraries/2013-March/019533.html
http://www.haskell.org/pipermail/libraries/2012-November/018831.html

This approach may also solve the orphan instance problem, but I have no 
idea how to design programmable instance selection.

However, I suspect that GHC assumes at several places that there is only 
one instance per pair of class and type. What about packing and 
unpacking of class dictionaries in existentially quantified types?
Yitzchak Gale | 26 Feb 20:07 2014

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

Johan Tibell wrote:
> we could change the first two PVP rules to...
> ...or _orphan_ instances were added or
> _any_ instances were removed...
> I believe this would result in less work for maintainers.

The burden is actually not nearly as onerous as it used
to be with the many great new Cabal features that allow
manually tweaking cabal's build plan in various ways.
Many thanks to Johan and the Cabal team!

But yes, I agree, this is a good change to PVP.
+1

Christian Maeder wrote:
>> 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.)

Henning Thielemann wrote:
> ...What about packing and unpacking of
> class dictionaries in existentially quantified types?

I strongly agree with Christian, and I thank Henning
for suggesting an implementation direction.

But - focus, focus, focus! Make believe I never said
that.

Thanks,
Yitz
Herbert Valerio Riedel | 26 Feb 14:47 2014
Picon

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

On 2014-02-26 at 13:37:24 +0100, 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.*

[...]

general +1 from me
Mario Blažević | 26 Feb 17:01 2014

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

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.
Leon Smith | 26 Feb 18:28 2014
Picon

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

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
Edward Kmett | 26 Feb 20:32 2014
Picon

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

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


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Yitzchak Gale | 26 Feb 21:12 2014

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

Edward Kmett wrote:
> 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.

Would it help to make an exception for "standards-track" libraries
like vector? In that case, orphan instances are expected to be
only temporarily orphan. Hopefully, they will all eventually make
their way to their permanent homes.

Thanks,
Yitz
Edward Kmett | 26 Feb 22:20 2014
Picon

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

Well, at the time I wrote that package vector was kind of out in left field and considered a 'big' dependency by many people. How perspectives change. ;)

It was originally written because Data.Vector.Vector used to have no instances for Foldable, Traversable, Monad, etc. and Roman at the time was against adding them, as they had comparatively low performance. 

It accreted the rest of the instances necessary for working with my other packages after it had already come into existence, largely due to the fact that my packages at the time were all struggling to have a separate Haskell 98 core, and adding Vector instances immediately destroyed that ambition.

Eventually Roman relented on adding the instances for the base classes, and I was left with a hollow shell of a package full of orphans. 

Moreover, as time has worn on the noises of people who want a simpler dependency structure resonates better with me than than the noises of folks who want me to maintain 4x as many packages to maintain distinctions that literally nobody is using. So I've started collapsing many packages together (many of my 4.0 updates were for this purpose).

Finally, vector moved into the platform.

So upon reflection, all of the reasons for the creation of that package are out dated. I'll look into just doing the dependency-inversion and moving the remaining instances for my classes out to the libraries defining them when I can muster that much willpower. ;)

Another package I had orphaned a bunch of instances on was aeson. Now that that too is platformed, I feel less guilty about depending on it directly.

tl;dr Rambling historical musings on why my vector-instances package is now a bad idea.

I'm just a flat +1 on this proposal now, no caveats.



On Wed, Feb 26, 2014 at 3:12 PM, Yitzchak Gale <gale <at> sefer.org> wrote:
Edward Kmett wrote:
> 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.

Would it help to make an exception for "standards-track" libraries
like vector? In that case, orphan instances are expected to be
only temporarily orphan. Hopefully, they will all eventually make
their way to their permanent homes.

Thanks,
Yitz

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Gmane