Gearing up (again) for the next release: 2014.2.0.0

[Vincent Hanquez]

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.

So what i'm proposing is, if you're still using an old version of a 
package, you can notify me about it, and I can fix it, just like what 
you would have done if there was an upper bound on base in some of my 
package and you'ld still be using this old package on a newer ghc.

At this point, I feel that the crux of your problem here seems to be 
linked to API changes more than upper bounds or PvP.

-- 
Vincent