kmx git

Commit

Hash : 51933578
Author :
Date : 2020-08-11T23:51:59

Revert "Remove autotools build support"

This reverts commit 01ac32aab2109681abc58bb2f96a4ef4a7f0c6df.

HarfBuzz release walk-through checklist:

Open gitk and review changes since last release.
- git diff $(git describe | sed 's/-.*//').. src/*.h prints all public API changes.
  
  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.
  
  If there’s a backward-incompatible API change (including deletions for API used anywhere), that’s a release blocker. Do NOT release.
Based on severity of changes, decide whether it’s a minor or micro release number bump,
Search for REPLACEME on the repository and replace it with the chosen version for the release.
Make sure you have correct date and new version at the top of NEWS file.
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).
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”
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.
Tag the release and sign it: Eg. “git tag -s 1.4.7 -m 1.4.7”. Enter your GPG password.
Build win32 bundle. See README.mingw.md.
Push the commit and tag out: “git push –follow-tags”.
Go to GitHub release page here, edit the tag, upload win32 bundle and NEWS entry and save. No need to upload source tarball as we rely to GitHub’s automatic tar.gz generation.

Source

RELEASING.md

HarfBuzz release walk-through checklist:

1. Open gitk and review changes since last release.

   * `git diff $(git describe | sed 's/-.*//').. src/*.h` prints all public API
     changes.

     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.

     If there's a backward-incompatible API change (including deletions for API
     used anywhere), that's a release blocker.  Do NOT release.

2. Based on severity of changes, decide whether it's a minor or micro release
   number bump,

3. Search for REPLACEME on the repository and replace it with the chosen version
   for the release.

4. Make sure you have correct date and new version at the top of NEWS file.

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).

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"

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.

9. Build win32 bundle.  See [README.mingw.md](README.mingw.md).

10. Push the commit and tag out: "git push --follow-tags".

11. Go to GitHub release page [here](https://github.com/harfbuzz/harfbuzz/releases),
    edit the tag, upload win32 bundle and NEWS entry and save.
    No need to upload source tarball as we rely to GitHub's automatic tar.gz generation.

kc3-lang/harfbuzz/RELEASING.md

Commit

Source

RELEASING.md