Re: Fwd: Release policies

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 wrote:

On Wed, Dec 13, 2017 at 7:06 PM, Boespflug, Mathieu 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-info...

--Gershom