[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

[timothyhobbs at seznam.cz]

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/c23e19cbe78cc6964f23fdb90
b7029c5ae54dd35





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 at 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 at malde.org> wrote:
> "Bryan O'Sullivan" <bos at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
(http://www.haskell.org/mailman/listinfo/haskell-cafe)



-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com(http://IvanMiljenovic.wordpress.com)

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
(http://www.haskell.org/mailman/listinfo/haskell-cafe)"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120816/53a3a562/attachment.htm>