From 61bcbad58da106a3a7d8f0e1410e9048fc333ecf Mon Sep 17 00:00:00 2001 From: Robert Bartel Date: Mon, 7 Oct 2024 13:06:18 -0400 Subject: [PATCH] Clarify steps in release management doc. --- doc/RELEASE_MANAGEMENT.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/doc/RELEASE_MANAGEMENT.md b/doc/RELEASE_MANAGEMENT.md index bab71035a8..8082bd3963 100644 --- a/doc/RELEASE_MANAGEMENT.md +++ b/doc/RELEASE_MANAGEMENT.md @@ -23,7 +23,10 @@ The release process can be summarized fairly simply: - Version numbering should follow [Semantic Versioning](https://semver.org/) and its typical `MAJOR.MINOR.PATCH` pattern 2. A release candidate branch, based on `master`, is created in the official OWP repo - The name of this branch will be `release-X` for version `X` -3. All necessary testing and quality pre-release tasks are performed using this release candiate branch +3. The version is incremented in the main [CMakeLists.txt](../CMakeLists.txt) + - Update the line setting the version, which will look something like `project(ngen VERSION x.y.z)` + - Then committed and pushed this change to the `release-X` branch +4. All necessary testing and quality pre-release tasks are performed using this release candidate branch - **TODO**: to be documented in more detail 4. (If necessary) Bug fixes, documentation updates, and other acceptable, non-feature changes are applied to the release branch - Such changes should go through some peer review process before inclusion in the official OWP branch (e.g., PRs, out-of-band code reviews, etc.)