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 <[email protected]> wrote: > On Wed, Dec 13, 2017 at 7:06 PM, Boespflug, Mathieu <[email protected]> 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 _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
