Re: Fwd: Release policies

"Boespflug, Mathieu" writes:

Hi Gerhom,

On 14 December 2017 at 00:19, Gershom B wrote:

...

Mathieu:

I think the points about better tooling for documenting the correct claims in the release process are well taken. Updating the release notes manually leaves way too much room for error.

Indeed, the release notes have historically been a massive headache. Happily, I wrote a bit of the necessary tooling to fix this a few weeks ago [1].

[1] e4dc2cd51902a8cd83476f861cf52996e5adf157

...

However, I think you are incorrect that GHC 8.2.1 and 8.2.2 did not have cabal-install 1.24 support. They did. it works with them.

They did, and indeed Stack too worked just fine with them, but that was assuming that integer-gmp-1.0.1.0 really was what was shipped in the tarballs, not what it was on Hackage (until it got recently revised). I don't know which version of integer-gmp-1.0.1.0 was the intended one. They both have the same version number and neither seems more authoritative than the other to me. Had the Hackage one been the one that shipped, then I'm not sure that cabal-install-1.24 would have worked. Stack broke the moment what was on Hackage and what was in GHC bindists did not line up anymore. And with release notes mentioning incorrect version numbers, harder still to tell.

I agree that the cabal files uploaded to Hackage should match what is released or, if not, there should be a very good reason for divergence. [snip]

...

The general motivation of making a "feature freeze" more of a "freeze all the moving parts, really" I do agree with. Having a real freeze is part of a better release process, and it should allow all the downstream consumers of everything more time to really catch up. This is just one instance of that need.

Agreed.

Also agreed. Cheers, - Ben