[GHC DevOps Group] Fwd: Release policies

[Michael Snoyman]

On Thu, Dec 14, 2017 at 12:27 PM, Boespflug, Mathieu <m at tweag.io> wrote:

[snip]

* 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?
>
>
Short answer: if there's a clear idea in advance of when this feature
freeze is going to happen, I think we can coordinate releases of downstream
tooling (Stack being the most important, but stackage-curator playing in as
well) so that 2 months is sufficient. I'll talk with the rest of the Stack
team to see if there are any concerns.

Longer answer: Stack intentionally avoids depending on the internals of
Cabal wherever possible. Instead of calling library functions directly from
within Haskell code to perform builds, for example, it interacts with the
Setup.hs files over their command line interface.[1] This has two results:

* Stack can usually start using new GHC/Cabal versions without a new Stack
release, since it's just shelling out for the actual build
* There's not usually very much code churn needed in Stack to upgrade to a
newer Cabal release

This past release was an exception because of all of the changes that
landed, both the new cabal grammar to support the ^>= operator (making the
old parser incapable of lossily parsing new files) and API changes (I think
mostly around Backpack, though there was some code cleanup as well). In
particular, the main interface we need from Cabal—the package description
data types and parser—changed significantly enough that it took significant
effort to upgrade. There were also new features added (like sub libraries
and foreign libraries) that weren't immediately supported by the old Stack
version, and had to be manually added in.

Tying this up: generally upgrading to a new Cabal release should be fine,
and the only concern I'd have is fitting it into a release schedule with
Stack. The complications that could slow that down are:

* Changes to the command line interface that Stack uses (hopefully those
are exceedingly rare)
* Major overhauls to the Stack-facing API

Michael

[1] This allows for more reproducible builds of older snapshots, insuring
that the exact same Cabal library is performing the builds
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20171215/f63ffc43/attachment-0001.html>