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
changes.
- [ ] Print all public API changes:
`git diff $(git describe | sed 's/-.*//').. src/*.h`
Document them in NEWS. All API and API semantic changes should be clearly
marked as API additions, API changes, or API deletions. Document
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.
- [ ] Document them in NEWS.
All API and API semantic changes should be clearly marked as API additions, API changes, or API deletions.
If there's a backward-incompatible API change (including deletions for API
used anywhere), that's a release blocker. Do NOT release.
- [ ] Document 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.
2. Based on severity of changes, decide whether it's a minor or micro release
number bump,
If there's a backward-incompatible API change (including deletions for API used anywhere), that's a release blocker.
Do NOT release.
3. Search for REPLACEME on the repository and replace it with the chosen version
for the release.
- [ ] Based on severity of changes, decide whether it's a minor or micro release number bump.
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.
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).
- [ ] Make sure you have correct date and new version at the top of NEWS file.
6. 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. Eg. "1.4.7"
- [ ] Bump version in line 3 of meson.build and configure.ac.
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.
8. Tag the release and sign it: Eg. "git tag -s 1.4.7 -m 1.4.7". Enter your
GPG password.
- [ ] Tag the release and sign it: e.g. `git tag -s 1.4.7 -m 1.4.7`.
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`.