Project: Copa (Provisioning / Security & Compliance)
File: maintainer-guidelines.md

This project uses to automatically generate the appropriate and changelog for a release based on . Of note to maintainers is the need to enforce an empty line-separate format: ```xml <HEADER> <-- blank line --> <BODY> <-- blank line --> <FOOTER> ``` For contributor PRs, instead of trying to ensure adherence in every commit message, it's easiest to adopt a strategy so that the PR description is used as the final commit description with the appropriate semantic release format. In addition to the semantic release types called out in the , there are several other categories supported by the that maintainers should be aware of: chore: Reserved for automated maintenance changes, such as minor version go dependency updates initiated by Dependabot. revert: Maintainers should use this to mark commits that revert a previous commit, followed by the header of the reverted commit. The message body should include the SHA of the reverted commit, as well as a clear description of the reason for the revert. style: This is unused for this project. There are also two special categories to be added to the that maintainers need to pay special attention to when merging changes: Breaking changes should be described in the footer as follows: ```text BREAKING CHANGE: <breaking change summary> <-- blank line --> <breaking change description & migration instructions> <-- blank line --> <-- blank line --> Closes #<issue number> ``` Note that this project currently uses the `allow-initial-development-versions` flag for go-semantic-release, so breaking changes will still be handled as minor releases until the workflow is updated for the v1.0.0 release. ```text DEPRECATED: <summary of deprecated feature> <-- blank line --> <deprecated feature description & migration/workaround instructions> <-- blank line --> <-- blank line --> Closes #<issue number> ``` To avoid inconsistencies in tagging and release branching, this project uses the GitHub Actions workflow to automate the creation of releases. Review the `main` branch to ensure that it has all the desired changes for the new release branch and that there are no PR merge workflows in flight. Click Run workflow on the against the `main` branch. This will: Create a new tag with the incremented semantic version (e.g. `v0.9.0`) against the latest commit in `main`. Create a new GitHub release against that tag with an automatically generated changelog. Build and upload the new release version of Copa to the GitHub release. Create a new release branch if it does not already exist (e.g. `release-0.9`) Verify that the workflow ran successfully and review the expected outputs listed above. Review the appropriate release branch that the revision patches (e.g. `release-0.9` for an anticipated new `v0.9.x` tag) to ensure that it has all the desired changes for the release and that there are no PR merge workflows in flight. If there are fixes in `main` intended for the patch release in the latest release branch, they need to be manually ported to the release branch first and the revision released from there. Click Run workflow on the against the target `release-x.y` branch. This will: Create a new tag with the incremented semantic version (e.g. `v0.9.4`) against the latest commit in the release branch. Create a new GitHub release against that tag with an automatically generated changelog. Build and upload the new release version of Copa to the GitHub release. Verify that the workflow ran successfully and review the expected outputs listed above.