Release Guide

Step 1: Update version

Change version in following path:

• CMakeLists.txt

# Check if VERSION is provided externally, otherwise default to 5.0.9
if(NOT DEFINED PROJECT_VERSION OR PROJECT_VERSION STREQUAL "")
    set(PROJECT_VERSION "5.0.9")
endif()

• pkgconfig.mk

# version major & minor 
PKG_MAJOR = 5
PKG_MINOR = 0

# version bugfix level. Example: PKG_EXTRA = 1
PKG_EXTRA = 0

# version tag. Examples: rc1, b2, post1 - or just comment out for no tag
PKG_TAG = post1

• include/capstone/capstone.h

// Capstone API version
#define CS_API_MAJOR 5
#define CS_API_MINOR 0

// Version for bleeding edge code of the Github's "next" branch.
// Use this if you want the absolutely latest development code.
// This version number will be bumped up whenever we have a new major change.
#define CS_NEXT_VERSION 6

// Capstone package version
#define CS_VERSION_MAJOR CS_API_MAJOR
#define CS_VERSION_MINOR CS_API_MINOR
#define CS_VERSION_EXTRA 0

...

#define CS_VERSION_PRE_RELEASE CS_VERSION_ALPHA9

Step 2: Update binding const

cd bindings
python3 const_generator.py all

Step 3: Check tests

• Ensure the CI on the release branch is all green

Step 4: Prepare release

• Update Changelog
  • Go to: Create new release
  • Select branch
  • In "Tag" select "Create new tag" (it won't actually be created).
  • Generate release notes and copy them to the Changelog file.
  • Return from page without creating the release (that is done later).
• Check version numbers as above:
  • Check/Update CMakeLists.txt version
  • Check/Update pkgconfig.mk version
  • Check/Update capstone.h version
• Update binding constants.
• Open PR with all these changes.
• Merge after review was done.

Step 5: Do release

Important

The upload of Python wheels will only trigger if the release is created and a tag is assigned (see: https://github.com/capstone-engine/capstone/pull/2766).

Important

The Actions triggering on release created won't run if the release was saved as Draft Release and then published.

This means: Do not write and save a Draft Release to publish it later. No binaries will be built.

Just publish it directly.

• Create tag
  • Locally run git tag -s x.y.z-alpha (example tag name of course).
    • Tag name must be of the form x.y.z-alpha. -alpha is optional and can be any addition. Tag name should NOT start with a v.
    • -s signs the tag. This is optional but recommended.
  • Push tag: git push upstream tag x.y.z-alpha
• Create release, with changelog and some highlights.
• Publish release directly (don't make it a draft release and publish it later!).

Step 6: After release

• If this was a major release, increment version numbers as above in the next branch (e.g. for a major release: v5, next should have CS_API_MAJOR 6 and CS_NEXT_VERSION 7).
• In case of a pre-release, update CS_VERSION_PRE_RELEASE to the next version.
• Close milestone associated with release version (move all the open issues to the next one).
• Update the website