9 Release Guide
Rot127 edited this page 2024-08-12 08:18:04 +00:00

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

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