kaguya
34 lines
1.5 KiB
Markdown
34 lines
1.5 KiB
Markdown
# Release Procedure
|
|
|
|
mlibc uses [semantic versioning v2.0.0](https://semver.org/spec/v2.0.0.html) to denote releases.
|
|
|
|
In short:
|
|
- A bump in the major version signals an ABI or API break, or otherwise any other major change
|
|
involving compatibility breakage.
|
|
- A bump in the minor version signals a newly released set of features, while still maintaining
|
|
compatibility.
|
|
- A bump in the patch signals a bug-fix, while not adding new features.
|
|
|
|
The `master` branch is where active development occurs, and where PRs get merged into. Changes
|
|
that are deemed appropriate to be backported to a major version branch (including the current,
|
|
latest major version branch) are cherry-picked there.
|
|
|
|
Releases are tagged off of their respective major version branches once they are ready.
|
|
|
|
Major versions get a new, dedicated branch, which is created from `master` when deemed
|
|
necessary, usually shortly before the tagging of the first release in the new major version
|
|
branch. This branch is called `vN.x`, where `N` is the number of the major version
|
|
(and `x` is just a literal "x").
|
|
|
|
Submodules are fixed to specific commits when a major version branch is created.
|
|
|
|
The first tag on the major version branch is the `vN.0.0` release.
|
|
|
|
Minor versions and patch versions are tagged on their respective major version branches
|
|
after the necessary commits are backported onto said branch from `master`.
|
|
|
|
## ABI_BREAKS.md
|
|
|
|
The `ABI_BREAKS.md` file should be updated in `master` alongside any newly merged commit that
|
|
does break ABI, in order to keep track of these changes.
|