... | ... | @@ -39,21 +39,18 @@ GHC releases fall into two categories: |
|
|
|
|
|
Major releases are currently produced twice a year. The schedule for a major release looks like this:
|
|
|
|
|
|
* **Fork**: a branch in the repository is created, named for the release, e.g. `ghc-9.8`
|
|
|
* **Fork**: a branch in the repository is created, named for the release, e.g. `ghc-9.8`.
|
|
|
* All changes to `base` package slated for the future release should be approved by CLC
|
|
|
and land before forking. Backports are usually reserved to security or packaging matters only.
|
|
|
* All breaking changes to boot packages (such as `bytestring` and `text`) should be
|
|
|
reflected in the GHC source tree by upgrading respective submodules before forking.
|
|
|
* **Alpha releases**: a series of pre-releases, called `alpha 1`, `alpha 2`, etc, allow GHC's developers and users to test the release.
|
|
|
* This prerelease window typically lasts three months, with an alpha every two-to-three weeks, resulting in four or five alphas.
|
|
|
* `base` library: We generally strive to have breaking changes in `base` in `alpha 1`, with non-breaking changes being in by `alpha 2` or `alpha 3`.
|
|
|
* Other boot libraries (e.g. `text`): should be finalized by `alpha 3`.
|
|
|
* Boot libraries should be finalised, including all minor changes,
|
|
|
and released by the penultimate alpha release (usually `alpha 3`).
|
|
|
* **Release candidate** is a release is supposed to be ready to go. Sometimes there is a quick succession of release candidates as minor glitches are fixed called `RC1`, `RC2`, etc.
|
|
|
* **Final release**.
|
|
|
|
|
|
Each release of GHC comes with a set of **boot libraries**. These packages come with GHC and cannot be updated independently of GHC. See [the boot library page](https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries) and [Guidelines for boot library maintainers](https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries). Concerning releases we have the following protocol:
|
|
|
* For the `base` package: all changes to `base` must happen before the `fork` step, except for security or packaging purposes.
|
|
|
* For other externally-maintained boot packages:
|
|
|
* If an external boot package plans a major release, it must land into GHC source tree before `fork`
|
|
|
* If only a minor release is planned, it must land before `alpha 3`.
|
|
|
* In both cases a release of a boot library must be finalised and uploaded onto Hackage by `alpha 3`.
|
|
|
|
|
|
### 1.2 Minor releases
|
|
|
|
|
|
Minor releases generally occur on an as-needed basis without a pre-determined schedule. But once we have decided to make a minor release, we post the schedule on the milestone. Unlike major releases, minor releases do not have an associated set of pre-releases.
|
... | ... | |