So that we are using concrete examples.  here is an example of a change that really shouldn't break any package:

https://github.com/timthelion/threadmanager/commit/c23e19cbe78cc6964f23fdb90b7029c5ae54dd35

The exposed functions are the same.  The behavior is changed.  But as the commiter of the change, I cannot imagine that it would break any currently working code.

There is another issue though.  With this kind of change, there is no reason for a package which was written for the old version of the library, to be built with the new version.  If I am correct, that this change changes nothing for currently working code, then why should an old package be built with the newer package?

The advantage in this case, is merely that we want to prevent version duplication.  We don't want to waste disk space by installing every possible iteration of a library.

I personally think that disk space is so cheep, that this last consideration is not so important.  If there are packages that only build with old versions of GHC, and old libraries, why can we not just seamlessly install them?  One problem, is if we want to use those old libraries with new code.  Take the example of Python2 vs Python3.  Yes, we can seamlessly install python2 libraries, even though we use python3 normally, but we cannot MIX python2 libraries with python3 libraries.

Maybe we could make Haskell linkable objects smart enough that we COULD mix old with new?  That sounds complicated.

I think, Michael Sloan is onto something though with his idea of compatibility layers.  I think that if we could write simple "dictionary" packages that would translate old API calls to new ones, we could use old code without modification.  This would allow us to build old libraries which normally wouldn't be compatible with something in base using a base-old-to-new dictionary package.  Then we could use these old libraries without modification with new code.

It's important that this be possible from the side of the person USING the library, and not the library author.   It's impossible to write software, if you spend all of your time waiting for someone else to update their libraries.

Timothy

---------- Původní zpráva ----------
Od: Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com>
Datum: 16. 8. 2012
Předmět: Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

On 16 August 2012 20:50, Ketil Malde <ketil@malde.org> wrote:
> "Bryan O'Sullivan" <bos@serpentine.com> writes:
>
>> I propose that the sense of the recommendation around upper bounds in the
>> PVP be reversed: upper bounds should be specified *only when there is a
>> known problem with a new version* of a depended-upon package.
>
> Another advantage to this is that it's not always clear what constitutes
> an API change. I had to put an upper bound on binary, since 0.5
> introduced laziness changes that broke my program. (I later got some
> help to implement a workaround, but binary-0.4.4 is still substantially
> faster). Understandably, the authors didn't see this as a breaking API
> change.

Except 0.4 -> 0.5 _is_ a major version bump according to the PVP.

>
> So, +1.
>
> -k
> --
> If I haven't seen further, it is by standing in the footprints of giants
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



--
Ivan Lazar Miljenovic
Ivan.Miljenovic@gmail.com
http://IvanMiljenovic.wordpress.com

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe