[GHC DevOps Group] Fwd: Release policies

[Boespflug, Mathieu]

Hi Gershom,

thanks for the extra input. So we've confirmed two facts:

* GHC (intended to) ship with only Cabal-2.0 support, but there was a
mistake in the release notes so this was unclear to downstream tooling
authors.
* Cabal-2.0 was released anywhere between slightly *after* and
*exactly at the same as* GHC, despite GHC itself shipping with
Cabal-2.0.

I'm not too concerned by the first point: so long as Cabal-X does not
introduce breaking changes, the fact that GHC-Y ultimately shipped
with Cabal-X shouldn't be a problem. And this kind of bug in the
release notes should go away provided more automation.

The second one is more interesting. It is, as you point out, a product
of GHC and Cabal being intimately linked and co-developed to a large
extent. This leads to a simultaneous release that poses a concrete
problem:

* if new Cabal versions are used immediately in GHC, then that gives
no time at all ahead of a GHC release for downstream tooling authors
to adapt, because Cabal is, up until the point of the GHC release, a
moving target.

Three possible solutions:

* Provided no API breaking changes in Cabal, if no metadata that ships
with GHC uses new Cabal features for some period of time before
release, then the problem goes away.
* Or something close to what Manuel proposed in another thread: ship
in GHC-X+1 the Cabal version that was co-developed during the
development cycle of GHC-X.
* Or a middle ground: make feature freeze a thing. Meaning that for a
couple of months before a major GHC release, the major new Cabal isn't
technically released yet, but like GHC itself within this period, it's
pretty staid, so not so much a moving target, and something downstream
tooling authors can possibly adapt to even without any grace period on
new metadata features. This assumes that the 2 months of feature
freeze are enough time for downstream tooling. Thoughts from any of
those maintainers?


On 14 December 2017 at 01:27, Gershom B <gershomb at gmail.com> wrote:
> On Wed, Dec 13, 2017 at 7:06 PM, Boespflug, Mathieu <m at tweag.io> wrote:
>>
>> 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?
>
> My understanding is that this is the general thought, yes. In fact,
> I've been told that even though cabal-install 1.24 did end up working
> with the GHC 8.2.x series, the release notes, which were not updated
> properly, actually _were supposed_ to say cabal-install 2.0.0.0 was
> what was supported there. I believe future cabal-installs will warn
> when used with a ghc with a newer Cabal-lib than they were built
> against...
>
>> 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?
>
> Right. After freeze, the compiler itself shouldn't switch from Cabal-2
> to Cabal-3. But I would imagine rather that the Cabal-3 tree and the
> compiler tree would be updated in tandem, and then the "freeze" would
> sort of apply to both in tandem as well. So there wouldn't be big
> changes after the freeze, but nor would the compiler be coupled to a
> _released_ lib. Rather, they would develop together, freeze together,
> and release together.
>
>> 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.
>
> Not exactly. The tarball of the package on hackage should match the
> release tarball. Revisions don't change the tarball. They just add
> additional metadata to the index as well that cabal-install knows how
> to use in conjunction with the tarball:
> https://github.com/haskell-infra/hackage-trustees/blob/master/revisions-information.md#what-are-revisions
>
> --Gershom