... | ... | @@ -15,12 +15,13 @@ 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`
|
|
|
* **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.
|
|
|
* **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 core libraries (`base`) in for alpha 1, with non-breaking changes being in by alpha 2 or 3.
|
|
|
* Other boot libraries (e.g. `text`): should be finalized by 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**.
|
|
|
|
|
|
We generally strive to have breaking changes in core libraries (`base`) in for alpha 1, with non-breaking changes being in by alpha 2 or 3. Similarly, boot library versions (e.g. `text`) should be finalized by alpha 3.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
... | ... | |