Skip to content

Compare: Making a release

Showing with 1 addition and 3 deletions.
  1. +1 −3 Making-a-release.md
4 changes: 1 addition & 3 deletions Making-a-release.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -81,9 +81,7 @@ Sometimes we make a major release of `cabal-install` along with the `Cabal` rele

The goal is to create or backport all needed PRs in this step so that the list of PRs is finalized before changelog generation and so no PRs are missed in the changelog. CI PRs are exempt since they emerge from much later steps to do with binary builds, but it's fine because they are not recorded in the changelog.

1. Make sure `cabal-version` of Cabal and Cabal-syntax is *not* the latest cabal file format version and that it is within the backwards compat range, which extends to 5 years back (bump, to give a good example to cabal users, only during a major release, never minor). Look at the [file format changelog](https://cabal.readthedocs.io/en/stable/file-format-changelog.html) to see which `cabal-version` was released five years ago (the SPDX License List version gives away the date).

3. Check for new `ghc` options: `comm -13 <(ghc-oldver --show-options | sort) <(ghc-newver --show-options | sort) | grep '^-f'`. Note that these can pop up in `ghc` minor versions! Options that do not change generated artifacts (most of them do, so cabal assumes the worst) need to be recorded in `Cabal/src/Distribution/Simple/Program/GHC.hs`. Add such options in `simpleFilters` if they take no parameters or integer parameters, otherwise in `argumentFilters`.
1. Check for new `ghc` options: `comm -13 <(ghc-oldver --show-options | sort) <(ghc-newver --show-options | sort) | grep '^-f'`. Note that these can pop up in `ghc` minor versions! Options that do not change generated artifacts (most of them do, so cabal assumes the worst) need to be recorded in `Cabal/src/Distribution/Simple/Program/GHC.hs`. Add such options in `simpleFilters` if they take no parameters or integer parameters, otherwise in `argumentFilters`.

5. Commit the changes to `master`, then backport them to the release branch. You may also want to backport to still-supported branches. (e.g. if we are releasing `3.12`, we will commit to `master`, backport to `3.12` *and* backport to `3.10`.)

Expand Down