Browse Source

docs(MAINTAINING): update release section and split into sections

reviewable/pr4517/r1
Zetok Zalbavar 8 years ago
parent
commit
ddc0723c5b
No known key found for this signature in database
GPG Key ID: C953D3880212068A
  1. 30
      MAINTAINING.md

30
MAINTAINING.md

@ -171,6 +171,8 @@ Follow steps for adding translations from Weblate up to step 5. Next:
# Releases # Releases
## Tagging scheme
- tag versions that are to be released, make sure that they are GPG-signed, - tag versions that are to be released, make sure that they are GPG-signed,
i.e. `git tag -s v1.8.0` i.e. `git tag -s v1.8.0`
- use semantic versions for tags: `vMAJOR.MINOR.PATCH` - use semantic versions for tags: `vMAJOR.MINOR.PATCH`
@ -186,22 +188,30 @@ Follow steps for adding translations from Weblate up to step 5. Next:
accordingly. accordingly.
- bumping a higher-level version "resets" lower-version numbers, e.g. - bumping a higher-level version "resets" lower-version numbers, e.g.
`v1.7.1 → v2.0.0` `v1.7.1 → v2.0.0`
- update version:
- bump version number in `cmake/Installation.cmake` ## Steps for release
- for windows/osx packages use the [`./tools/update-versions.sh`] script,
e.g. `./tools/update-versions.sh 1.11.0` ### Before tagging
- before creating a `MAJOR`/`MINOR` release generate changelog with `clog`.
- in a `MAJOR`/`MINOR` release tag should include information that changelog - Update version number for windows/osx packages using the
[`./tools/update-versions.sh`] script, e.g. `./tools/update-versions.sh
1.11.0`
- Generate changelog with `clog`.
- In a `MAJOR`/`MINOR` release tag should include information that changelog
is located in the `CHANGELOG.md` file, e.g. `For details see CHANGELOG.md` is located in the `CHANGELOG.md` file, e.g. `For details see CHANGELOG.md`
- to release a `PATCH` version after non-fix changes have landed on `master` - To release a `PATCH` version after non-fix changes have landed on `master`
branch, checkout latest `MAJOR`/`MINOR` version and `git cherry-pick -x` branch, checkout latest `MAJOR`/`MINOR` version and `git cherry-pick -x`
commits from `master` that you want `PATCH` release to include. Once commits from `master` that you want `PATCH` release to include. Once
cherry-picking has been done, tag HEAD of the branch. cherry-picking has been done, tag HEAD of the branch.
- when making a `PATCH` tag, include in tag message short summary of what the - When making a `PATCH` tag, include in tag message short summary of what the
tag release fixes, and to whom it's interesting (often only some tag release fixes, and to whom it's interesting (often only some
OSes/distributions would find given `PATCH` release interesting). OSes/distributions would find given `PATCH` release interesting).
- create and GPG-sign tarball using [`./tools/create-tarball.sh`] script, and
upload the tarball to a github release. ### After tagging
- Create and GPG-sign tarball using [`./tools/create-tarball.sh`] script, and
upload the tarball to the github release that was created by a Travis OSX
release job.
# How to become a maintainer? # How to become a maintainer?

Loading…
Cancel
Save