RELEASING.md

   1 # HarfBuzz release walk-through checklist:
   2
   3 - [ ] Open gitk and review changes since last release.
   4
   5         - [ ] Print all public API changes:
   6         `git diff $(git describe | sed 's/-.*//').. src/*.h`
   7
   8     - [ ]  Document them in NEWS.
   9         All API and API semantic changes should be clearly marked as API additions, API changes, or API deletions.
  10
  11     - [ ] Document deprecations.
  12         Ensure all new API / deprecations are in listed correctly in docs/harfbuzz-sections.txt.
  13         If release added new API, add entry for new API index at the end of docs/harfbuzz-docs.xml.
  14
  15      If there's a backward-incompatible API change (including deletions for API used anywhere), that's a release blocker.
  16      Do NOT release.
  17
  18 - [ ] Based on severity of changes, decide whether it's a minor or micro release number bump.
  19
  20 - [ ] Search for 'XSince: REPLACEME' on the repository and replace it with the chosen version for the release, e.g. 'Since: 1.4.7'.
  21
  22 - [ ] Make sure you have correct date and new version at the top of NEWS file.
  23
  24 - [ ] Bump version in line 3 of meson.build and configure.ac.
  25
  26 - [ ] 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).
  27
  28 - [ ] Commit NEWS, meson.build, configure.ac, and src/hb-version.h, as well as any REPLACEME changes you made.
  29         The commit message is simply the release number, e. g. "1.4.7"
  30
  31 - [ ] Do a `meson dist -Cbuild` that runs the tests against the latest committed changes.
  32    If doesn't pass, something fishy is going on, reset the repo and start over.
  33
  34 - [ ] Tag the release and sign it: e.g. `git tag -s 1.4.7 -m 1.4.7`.
  35           Enter your GPG password.
  36
  37 - [ ] Push the commit and tag out: `git push --follow-tags`.