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

[Chris Dornan]

Of course if you wish or need to upgrade a package then you can just upgrade
it -- I am not suggesting anyone should forgo upgrades! It is just that
there is no need to make the stability of a build process dependent on new
package releases.

To upgrade a package I would fork my sandbox, hack away at the package
database (removing, upgrading, installing packages) until I have a candidate
combination of packages and swap in the new sandbox into my work tree and
test it, reverting to the tried and tested environment if things don't work
out.  If the new configuration works then then I would dump the new package
configuration and check it in. Subsequent updates and builds on other work
trees should pick up the new environment.

The key thing I was looking for was control of when your build environment
gets disrupted and stability in between -- even when building from the repo.

Chris

-----Original Message-----
From: Erik Hesselink [mailto:hesselink at gmail.com] 
Sent: 20 August 2012 14:35
To: Chris Dornan
Cc: Bryan O'Sullivan; haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not
our friends

Hub looks interesting, I'll have to try it out (though I'm not on an RPM
based distro). But isn't this the goal of things like semantic versioning
[0] and the PVP? To know that you can safely upgrade to a bugfix release,
and relavily safely to a minor release, but on a major release, you have to
take care?

Haskell makes it much easier to see if you can use a new major (or
minor) version of a library, since the type checker catches many (but not
all!) problems for you. However, this leads to libraries breaking their
API's much more easily, and that in turn causes the problems voiced in this
thread. However, fixing all versions seems like a bit of a blunt instrument,
as it means I'll have to do a lot of work to bring even bug fixes in.

Erik

[0] http://semver.org/



On Mon, Aug 20, 2012 at 3:13 PM, Chris Dornan <chris at chrisdornan.com> wrote:
> I think we should encourage stable build environments to know 
> precisely which package versions they have been using and to keep 
> using them until told otherwise. Even when the types and constraints 
> all work out there is a risk that upgraded packages will break. 
> Everybody here wants cabal to just install the packages without 
> problem, but if you want to insulate yourself from package upgrades 
> surely sticking with proven combinations is the way to go.
>
> Chris
>
> -----Original Message-----
> From: haskell-cafe-bounces at haskell.org 
> [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Erik Hesselink
> Sent: 20 August 2012 08:33
> To: Bryan O'Sullivan
> Cc: haskell-cafe at haskell.org
> Subject: Re: [Haskell-cafe] Platform Versioning Policy: upper bounds 
> are not our friends
>
> I am strongly against this, especially for packages in the platform.
>
> If you fail to specify an upper bound, and I depend on your package, 
> your dependencies can break my package! For example, say I develop 
> executable A and I depend on library B == 1.0. Library B depends on 
> library C >= 0.5 (no upper bound). Now C 0.6 is released, which is 
> incompatible with B. This suddenly breaks my build, even though I have 
> not changed anything about my code or dependencies. This goes against 
> the 'robust' aspect mentioned as one of the properties of the Haskell 
> platform, and against the Haskell philosophy of correctness in general.
>
> This is not an imaginary problem. At my company, we've run into these 
> problems numerous times already. Since we also have people who are not 
> experts at Cabal and the Haskell ecosystem building our software, this 
> can be very annoying. The fix is also not trivial: we can add a 
> dependency on a package we don't use to all our executables or we can 
> fork the library (B, in the example above) and add an upper bound/fix 
> the code. Both add a lot of complexity that we don't want. Add to that 
> the build failures and associated emails from CI systems like Jenkins.
>
> I can see the maintenance burder you have, since we have to do the 
> same for our code. But until some Cabal feature is added to ignore 
> upper bounds or specify soft upper bounds, please follow the PVP, also 
> in this regard. It helps us maintain a situation where only our own 
> actions can break our software.
>
> Erik
>
> On Wed, Aug 15, 2012 at 9:38 PM, Bryan O'Sullivan <bos at serpentine.com>
> wrote:
>> Hi, folks -
>>
>> I'm sure we are all familiar with the phrase "cabal dependency hell"
>> at this point, as the number of projects on Hackage that are intended 
>> to hack around the problem slowly grows.
>>
>> I am currently undergoing a fresh visit to that unhappy realm, as I 
>> try to rebuild some of my packages to see if they work with the GHC
>> 7.6 release candidate.
>>
>> A substantial number of the difficulties I am encountering are 
>> related to packages specifying upper bounds on their dependencies. 
>> This is a recurrent problem, and its source lies in the 
>> recommendations of the PVP itself (problematic phrase highlighted in
bold):
>>
>>> When publishing a Cabal package, you should ensure that your 
>>> dependencies in the build-depends field are accurate. This means 
>>> specifying not only lower bounds, but also upper bounds on every
> dependency.
>>
>>
>> I understand that the intention behind requiring tight upper bounds 
>> was good, but in practice this has worked out terribly, leading to 
>> depsolver failures that prevent a package from being installed, when 
>> everything goes smoothly with the upper bounds relaxed. The default 
>> response has been for a flurry of small updates to packages in which 
>> the upper bounds are loosened, thus guaranteeing that the problem 
>> will recur in a year or less. This is neither sensible, fun, nor
sustainable.
>>
>> In practice, when an author bumps a version of a depended-upon 
>> package, the changes are almost always either benign, or will lead to 
>> compilation failure in the depending-upon package. A benign change 
>> will obviously have no visible effect, while a compilation failure is 
>> actually better than a depsolver failure, because it's more informative.
>>
>> This leaves the nasty-but-in-my-experience-rare case of runtime 
>> failures caused by semantic changes. In these instances, a downstream 
>> package should reactively add an upper bound once a problem is
discovered.
>>
>> 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.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>