Fwd: Release policies

[Boespflug, Mathieu]

Hi Gerhom,

On 14 December 2017 at 00:19, Gershom B <gershomb at gmail.com> 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.
>
> 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.

But crucially, what *is* the policy around Cabal versions? This
comment, https://ghc.haskell.org/trac/ghc/ticket/14558#comment:23
claims "if Stack doesn't support the version of Cabal that ships with
a certain version of GHC, it shouldn't claim that it supports that
version of GHC. The same applies to cabal-install". Is any build tool
linked against Cabal-X by definition "not a supported configuration"
by GHC-Z if it ships with Cabal-Y such that X < Y?

> > * Stronger still, GHC should not switch to a new major release of a
> > dependency at any time during feature freeze ahead of a release. E.g. if
> > Cabal-3.0.0 ships before feature freeze for GHC-9.6, then maybe it's fair
> > game to include in GHC. But not if Cabal-3.0.0 hasn't shipped yet.
>
> I don't think this works, in terms of coupled dependencies. If/when
> Cabal-3 is developed it will almost certainly be in tandem with GHC
> support.

Right. But switching from Cabal-2 to Cabal-3 (a hypothetical at this
point) sounds like a whole new set of features transitively just made
it into the compiler. Is that something we're happy to happen during
feature freeze?

> 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.

> > Finally, a question for discussion:
> >
> > * Hackage allows revising the metadata of an uploaded package even without
> > changing the version number. This happens routinely on Hackage today by the
> > Hackage trustees. Should this be permitted for packages whose release is
> > completely tied to that of GHC itself (like integer-gmp)?
>
> It is rare that this is needed, but the ability just served us well --
> editing integer-gmp to remove the new syntax was very useful, as it
> let us fix up old stack nightlies. Like all revisions, these should be
> made with some care and thought, but since we've just seen why it was
> helpful, I'd hate to now say we can't do it again if some other
> unforseen circumstance crops up.

I don't disagree. But then we'd need to abandon any notion that
versions of packages on Hackage and versions of packages in the GHC
release tarball always match up. Might even be worth calling that out
explicitly in the policy.