From 68a89d2473687fef5201570c938fd8b5ed44ccc6 Mon Sep 17 00:00:00 2001 From: Anonymoussaurus <50231698+AnonymousWP@users.noreply.github.com> Date: Sun, 9 Mar 2025 13:26:09 +0100 Subject: [PATCH] docs(release): move part of contributing to release file --- CONTRIBUTING.md | 36 +----------------------------------- RELEASE.md | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 33 insertions(+), 35 deletions(-) create mode 100644 RELEASE.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ea30c85..3fd6a78 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -24,46 +24,12 @@ Do mind that these branch names do only not apply to the addition of packages; f This is how it looks like and works: ![Trunk-Based Development](https://trunkbaseddevelopment.com/trunk1c.png) - ### Syncing branches + If you want to [back-port](https://en.wikipedia.org/wiki/Backporting) (GitHub's "Update" and "Sync" buttons) from upstream `main` to any other branch (for testing purposes, or any other reasonable case), it's recommended that you `rebase` rather than `merge` the changes. **Don't apply changes to/from arbitrary branches**, that's a recipe for chaos! If you encounter a situation where it's absolutely necessary to sync non-`main` branches, whether to `merge` or `rebase` should be decided by the UAD-ng team (with some contributor feedback) on a case-by-case basis. - ### Commit messages As for commits, we prefer using [Conventional Commit Messages](https://gist.github.com/qoomon/5dfcdf8eec66a051ecd85625518cfd13). When working in any of the branches listed above (if there's an existing issue for it), close it using a [closing keyword](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword). For more information regarding Conventional Commit Messages, see as well. - -### Release management - -#### Semantic versioning - -We're making use of [semantic versioning](https://semver.org/). We use semantic versioning for two things: - -1. GitHub Milestones -1. UAD-ng releases - -Speaking of milestones: it could be that we have a bug-fix release (e.g. 1.0.3), but a contributor submits a PR that adds a new feature. What do we do? Merge after we released 1.0.3? Change the name of the milestone to for example 1.1.0? Or another approach? - -In that case, we should closely review the PR and 'compare' it with what semantic versioning has to say about the submitted feature. If the changes are significant enough, we're renaming the milestone to (for example) 1.1.0. - -#### Checklist before releasing a new version - -- [ ] Make sure the Milestone is completed and if not, check what needs to be done to complete it. -- [ ] Make sure all merged PRs regarding the application follow the Conventional Commit Messages style. This makes sure that when generating a changelog, the changes look consistent, which in turn improves readability. -- [ ] Make sure all merged PRs have the correct labels assigned, as the changelog is generated based on labels. -- [ ] Create a release preparation PR that bumps the Rust package version in `Cargo.toml` and `Cargo.lock` - -When all the above has been checked, you can push a tag to `main` to trigger the GitHub Action that creates a release: - -- Create the tag: `git tag -s v1.2.3 -am '1.2.3'` -- Push the tag: `git push origin v1.2.3` - -Change the version number to whatever version we're releasing. - -#### Faulty releases - -If we publish a faulty release, for example containing a critical bug, this is how we should deal with it: - -We issue a hotfix and keep the faulty release but we'll add warnings to the faulty release in the changelog. diff --git a/RELEASE.md b/RELEASE.md new file mode 100644 index 0000000..bd7f64e --- /dev/null +++ b/RELEASE.md @@ -0,0 +1,32 @@ +# Release management + +## Semantic versioning + +We're making use of [semantic versioning](https://semver.org/). We use semantic versioning for two things: + +1. GitHub Milestones +1. UAD-ng releases + +Speaking of milestones: it could be that we have a bug-fix release (e.g. 1.0.3), but a contributor submits a PR that adds a new feature. What do we do? Merge after we released 1.0.3? Change the name of the milestone to for example 1.1.0? Or another approach? + +In that case, we should closely review the PR and 'compare' it with what semantic versioning has to say about the submitted feature. If the changes are significant enough, we're renaming the milestone to (for example) 1.1.0. + +## Checklist before releasing a new version + +- [ ] Make sure the Milestone is completed and if not, check what needs to be done to complete it. +- [ ] Make sure all merged PRs regarding the application follow the Conventional Commit Messages style. This makes sure that when generating a changelog, the changes look consistent, which in turn improves readability. +- [ ] Make sure all merged PRs have the correct labels assigned, as the changelog is generated based on labels. +- [ ] Create a release preparation PR that bumps the Rust package version in `Cargo.toml` and `Cargo.lock` + +When all the above has been checked, you can push a tag to `main` to trigger the GitHub Action that creates a release: + +- Create the tag: `git tag -s v1.2.3 -am '1.2.3'` +- Push the tag: `git push origin v1.2.3` + +Change the version number to whatever version we're releasing. + +## Faulty releases + +If we publish a faulty release, for example containing a critical bug, this is how we should deal with it: + +We issue a hotfix and keep the faulty release but we'll add warnings to the faulty release in the changelog.