- Update translations submodule https://github.com/rizinorg/cutter-translations
The latest archive from Crowdin should already be in the repository, if not make sure to merge any automated Pull Request from Crowdin (e.g. https://github.com/rizinorg/cutter-translations/pull/9)
Update submodule in cutter
Merge the current state of dev into stable. This can happen even earlier in order to feature-freeze the release while keeping development on dev alive. The rizin submodule on stable should point to a commit of stable in rizin and dev to a commit in dev.
Lock rzghidra and rzdec versions downloaded by packaging scripts. Specify a tag or commit hash.
- Update version
To be safe, search the code base for the previous version number.
- Create a tag for the release candidate. For example, for the v1.11.0 release you’d do something like this:
git tag v1.11.0-rc1
git tag push origin v1.11.0-rc1
Create a GitHub release, mark it as pre-release save draft, set the tag to v1.11.0-rc1
Wait for packages to build
On all operating systems do the Basic testing procedure to ensure nothing badly broken.
If any major problems are found, open an issue and fix them in dev and cherry pick into release branch. If the amount of changes is sufficiently large repeat from step 3. increasing rc number by one.
Update version to 1.11.0
Create release * Fill the release notes in the Release description. Preparing release notes can begin earlier. Compare current dev branch against previous release to find all the changes. Choose the most important ones. Don’t duplicate the commit log. Release notes should be a summary for people who don’t want to read whole commit log. Group related changes together under titles such as “New features”, “Bug Fixes”, “Decompiler”, “Rizin” and similar.
Prepare announcement tweets and messages to send in the Telegram group, reddit, and others.
Close milestone if there was one
The process for bugfix release is similar no normal release procedure described above with some differences.
Cherry pick required bugfixes from dev into the stable.
Increase the third version number x.y.n into x.y.(n+1) .
Basic testing procedure¶
This isn’t intended as exhaustive testing process, just some simple steps to make sure nothing is badly broken. If it makes sense repeat the step multiple times at different offsets and click around increase the chance of noticing common problems that doesn’t happen 100% of time.
Open a simple executable like
Make sure that the upgraded layout isn’t completely broken
The Disassembly widget shows proper disassembly.
- Bundled plugins work
Open decompiler and select ghidra, it shows some C code at least for some functions
Open rzdec in decompiler widget, make sure it shows code
Test that sample python plugin works
- Try debugger
Insert breakpoint in main
Go to main using function widget, make sure relocation was done correctly and you see code instead of unmapped memory and breakpoint is where you placed
Click continue until you hit breakpoint in main
Delete cutter settings file, and test that clean start works and layout isn’t broken