-
Notifications
You must be signed in to change notification settings - Fork 26
Releases
GitHub can provide automated changelogs on the release page if you use their web interface to do the creation. See here for more details https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release
Only sleigh_GHIDRA_RELEASE_TYPE=stable configurations should be uploaded to the release page.
Tags should start with v and include at least the upstream Ghidra version for which the release is being created.
If only packaging changes have occurred, then a bump to the CPack PACKAGE_VERSION should be made, and the tag should include this, unless it's the first release for the upstream version, i.e. tag order like v10.1.2, v10.1.2-2, v10.1.2-3, etc.
When a new upstream release is created, the CPack PACKAGE_VERSION should reset to 1. We choose 1 because we are creating an unofficial release with packaging. (NOTE: In the event that someone wants to package this repo, then I'm not sure what a distro package maintainer will want to do for their versioning, but I'm open to suggestions)
The PACKAGE_VERSION should be incremented whenever a release is to be made with any changes to the CMake files and the upstream has not created a new release. Until we can figure out a better method for semantic versioning of the packaging logic/functionality, I think this might be the best way to do things... I'm open to suggestions if there is a better way.