Gearing up (again) for the next release: 2014.2.0.0

[Erik Hesselink]

On Thu, Apr 10, 2014 at 5:02 PM, Vincent Hanquez <tab at snarc.org> wrote:
> On 2014-04-10 15:22, Gregory Collins wrote:
>
>>
>> On Thu, Apr 10, 2014 at 4:01 PM, Vincent Hanquez <tab at snarc.org
>> <mailto:tab at snarc.org>> wrote:
>>
>>     You could have notified me about the fact that you're still using
>>     an 1.5 year outdated package, I could reupload a newer tls-1.0.x
>>     branch package with the upper bound on cryptocipher. it would take
>>     me 1 minute.
>>
>>
>> That's sort of irrelevant IMO. Old code that was working fine before
>> shouldn't rot just because it's old -- I've had plenty of breakages in this
>> particular testsuite in the past (please just take my word for it and don't
>> make me look them all up :)) where I was using some older version of
>> http-enumerator/conduit, got into a tls/cryptocipher/etc build breakage
>> because of the lack of upper bounds, tried to upgrade http-conduit to latest
>> version and then got a bunch of build breakages because the http-conduit
>> APIs had changed.
>>
>> At that point I have a project on my hands: sure I could track you down
>> and ask you to add upper bounds to your old packages, or get on the Hackage
>> upgrade treadmill and update that code to the latest version of that API,
>> but your decision not to follow the PVP is what caused the breakage in the
>> first place --- and as people have been complaining since you guys started
>> on this "remove all the upper bounds" Don Quixote quest, build breakages due
>> to this are inevitable unless you never change your APIs again. Frankly,
>> just giving cabal the information it needed to generate a valid build plan
>> was the lowest-friction option for me here. We don't use http-conduit in the
>> git master snap-server testsuite anymore (precisely because I'm sick of
>> fixing these build breakages), so I did the least amount of work possible to
>> keep the 0.9-stable branch working.
>>
>> TL;DR: complaining because I didn't notify you that your decision to omit
>> upper bounds caused me a build breakage seems weird to me: we've been
>> protesting that this is an inevitable consequence for a long time now.
>
>
> I never protested this is a consequence. Old unmaintained packages stop
> building eventually, this is just a fact that even the strict PvP *cannot*
> stop.
>
> The simplest canonical example is that if I had follow the PvP in tls 1.0.x
> and have upper bounds on base, it would have stop building at the next ghc
> release.

This is false. It will not work on the new GHC, and it has never
worked on the new GHC. It will, however, keep working on the GHC is
was originally developed on, and will keep working there. This is a
very desirable property.

Also, you say 'old' packages. Right now, we cannot build things that
are about a month old, due to dependencies missing upper bounds on
their dependencies. Is one month 'old'?

Erik