[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
timothyhobbs at seznam.cz
timothyhobbs at seznam.cz
Thu Aug 16 15:48:07 CEST 2012
So that we are using concrete examples. here is an example of a change that
really shouldn't break any package:
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
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
---------- 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
"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
Except 0.4 -> 0.5 _is_ a major version bump according to the PVP.
> So, +1.
> If I haven't seen further, it is by standing in the footprints of giants
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe