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

Johan Tibell johan.tibell at gmail.com
Wed Feb 26 14:59:23 UTC 2014


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@ 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140226/9ac27733/attachment-0001.html>


More information about the Libraries mailing list