walkero
/
harfbuzz
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

[releasing] Format notes as Markdown checklist for pasting in GH PR/Issue

This commit is contained in:
Caleb Maclennan 2021-07-08 21:19:57 +03:00 committed by Behdad Esfahbod
parent eda5dcdb3e
commit eee36bbea3
1 changed files with 24 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
RELEASING.md
View File

@ -1,38 +1,37 @@
HarfBuzz release walk-through checklist: # HarfBuzz release walk-through checklist:
1. Open gitk and review changes since last release. - [ ] Open gitk and review changes since last release.
* `git diff $(git describe | sed 's/-.*//').. src/*.h` prints all public API - [ ] Print all public API changes:
changes. `git diff $(git describe | sed 's/-.*//').. src/*.h`
Document them in NEWS. All API and API semantic changes should be clearly - [ ] Document them in NEWS.
marked as API additions, API changes, or API deletions. Document All API and API semantic changes should be clearly marked as API additions, API changes, or API deletions.
deprecations. Ensure all new API / deprecations are in listed correctly in
docs/harfbuzz-sections.txt. If release added new API, add entry for new
API index at the end of docs/harfbuzz-docs.xml.
If there's a backward-incompatible API change (including deletions for API - [ ] Document deprecations.
used anywhere), that's a release blocker. Do NOT release. Ensure all new API / deprecations are in listed correctly in docs/harfbuzz-sections.txt.
If release added new API, add entry for new API index at the end of docs/harfbuzz-docs.xml.
2. Based on severity of changes, decide whether it's a minor or micro release If there's a backward-incompatible API change (including deletions for API used anywhere), that's a release blocker.
number bump, Do NOT release.
3. Search for REPLACEME on the repository and replace it with the chosen version - [ ] Based on severity of changes, decide whether it's a minor or micro release number bump.
for the release.
4. Make sure you have correct date and new version at the top of NEWS file. - [ ] Search for REPLACEME on the repository and replace it with the chosen version for the release.
5. Bump version in line 3 of meson.build and configure.ac. - [ ] Make sure you have correct date and new version at the top of NEWS file.
Do a `meson test -Cbuild` so it both checks the tests and updates
hb-version.h (use `git diff` to see if is really updated).
6. Commit NEWS, meson.build, configure.ac, and src/hb-version.h, as well as any REPLACEME - [ ] Bump version in line 3 of meson.build and configure.ac.
changes you made. The commit message is simply the release number. Eg. "1.4.7"
7. Do a `meson dist -Cbuild` that runs the tests against the latest commited changes. - [ ] Do a `meson test -Cbuild` so it both checks the tests and updates hb-version.h (use `git diff` to see if is really updated).
- [ ] Commit NEWS, meson.build, configure.ac, and src/hb-version.h, as well as any REPLACEME changes you made.
The commit message is simply the release number, e. g. "1.4.7"
- [ ] Do a `meson dist -Cbuild` that runs the tests against the latest commited changes.
If doesn't pass, something fishy is going on, reset the repo and start over. If doesn't pass, something fishy is going on, reset the repo and start over.
8. Tag the release and sign it: Eg. "git tag -s 1.4.7 -m 1.4.7". Enter your - [ ] Tag the release and sign it: e.g. `git tag -s 1.4.7 -m 1.4.7`.
GPG password. Enter your GPG password.
9. Push the commit and tag out: "git push --follow-tags". - [ ] Push the commit and tag out: `git push --follow-tags`.