... | ... | @@ -24,6 +24,13 @@ Major releases are currently produced twice a year. The schedule for a major rel |
|
|
* **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, if 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.
|
... | ... | |