Re: Gearing up (again) for the next release: 2014.2.0.0

On 2014-04-10 15:22, Gregory Collins wrote:

On Thu, Apr 10, 2014 at 4:01 PM, Vincent Hanquez mailto:tab@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