-
Notifications
You must be signed in to change notification settings - Fork 22
Releases
When a tag is pushed, the CI will run to create packages that will be uploaded for release.
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, as these are the artifacts that belong to a tagged stable version of upstream Ghidra.
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 affecting stable 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.