Release Guide

Step 1: Update version

Change version in following path:

• CMakeLists.txt

• 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

• bindings/python/capstone/__init__.py

# API version
CS_API_MAJOR = 5
CS_API_MINOR = 0

# Package version
CS_VERSION_MAJOR = CS_API_MAJOR
CS_VERSION_MINOR = CS_API_MINOR
CS_VERSION_EXTRA = 0

Step 2: Update binding const

cd bindings
python3 const_generator.py all

Step 3: Run tests manually

• Ensure the CI on the release branch is all green
• Go to own fork
• Ensure the release branch is the default branch (otherwise we cannot trigger workflows manually).
• Goto: Actions -> workflows -> RELEASE BUILD ... and run it.
• Ensure it is green.

Step 4: Prepare release

• Draft release message
• Update the changelog

Step 4: Do pre-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.

• Add the <version>-pre0 tag

• Crate a pre-release

• Ensure pypip uploads work as expected.

• If something fails, delete tag, push/merge fix, start again with incremented <version>-preX tag.

• Assign <version> tag

• Create full release.

Step 5: 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).
• Close milestone associated with release version (move all the open issues to the next one).