From e22088a8cf41d760b1d1e4d003d21fdba627160f Mon Sep 17 00:00:00 2001 From: Dave Wilding Date: Fri, 29 Nov 2024 08:13:36 +0800 Subject: [PATCH 1/5] updated guidance about CHANGES.md --- HACKING.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/HACKING.md b/HACKING.md index 2873ede45..1bdc6ebe5 100644 --- a/HACKING.md +++ b/HACKING.md @@ -401,7 +401,7 @@ filtered in/out. ### CHANGES.md A changelog is kept in version control that simply lists the changes in each -release, other than chores like bumping version numbers. The changelog for `ops` +release, other than chores. The changelog for `ops` is at the top level, in [CHANGES.md](CHANGES.md), and the changelog for `ops-scenario` is in the `/testing` folder, [CHANGES.md](testing/CHANGES.md). There will be overlap between the two files, as many PRs will include changes to @@ -414,8 +414,12 @@ CHANGES.md files. * Group the changes by the commit type (feat, fix, and so on) and use full names ("Features", not "feat", "Fixes", not "fix") for group headings. -* Remove any bullets that do not apply to the package (`ops` only changes for - `ops-scenario`, and `ops-scenario` only changes for `ops`). +* Remove any chores. +* Remove any bullets that do not apply to the package. For instance, if a bullet + only affects `ops[testing]`, don't include it in [CHANGES.md](CHANGES.md) when + doing an `ops` release. The bullet should go in [testing/CHANGES.md](testing/CHANGES.md) + instead. If `ops[testing]` is not being released yet, put the bullet in a placeholder + section at top of [testing/CHANGES.md](testing/CHANGES.md). * Strip the commit type prefix from the bullet point, and capitalise the first word. * Strip the username (who did each commit) if the author is a member of the @@ -423,6 +427,7 @@ CHANGES.md files. * Replace the link to the pull request with the PR number in parentheses. * Where appropriate, collapse multiple tightly related bullet points into a single point that refers to multiple commits. +* Where appropriate, add backticks for code formatting. For example: the PR From e2698b6274c338e4fed2f0b8c7d5a40dac4ee349 Mon Sep 17 00:00:00 2001 From: Dave Wilding Date: Fri, 29 Nov 2024 08:14:59 +0800 Subject: [PATCH 2/5] fixed markdown typo --- HACKING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/HACKING.md b/HACKING.md index 1bdc6ebe5..5e6d42ef3 100644 --- a/HACKING.md +++ b/HACKING.md @@ -342,7 +342,7 @@ To make a release of the `ops` and/or `ops-scenario` packages, do the following: 8. For `ops`, change [version.py](ops/version.py)'s `version` to the appropriate string. For `ops-scenario`, change the version in [testing/pyproject.toml](testing/pyproject.toml). Both packages use - [semantic versioning]](https://semver.org/), and adjust independently + [semantic versioning](https://semver.org/), and adjust independently (that is: ops 2.18 doesn't imply ops-scenario 2.18, or any other number). 9. Add, commit, and push, and open a PR to get the changelogs and version bumps into main (and get it merged). From 10ef070d98ffd9738cb46dde8374b563c20a270b Mon Sep 17 00:00:00 2001 From: Dave Wilding Date: Fri, 29 Nov 2024 09:54:39 +0800 Subject: [PATCH 3/5] updated guidance on release titles --- HACKING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/HACKING.md b/HACKING.md index 5e6d42ef3..7b84d0312 100644 --- a/HACKING.md +++ b/HACKING.md @@ -327,9 +327,9 @@ To make a release of the `ops` and/or `ops-scenario` packages, do the following: 2. Visit the [releases page on GitHub](https://github.com/canonical/operator/releases). 3. Click "Draft a new release" 4. The "Release Title" is the full version numbers of ops and/or ops-scenario, - in the form `ops .. and ops-scenario ..` + in the form `.. and ops[testing] ..` and a brief summary of the main changes in the release. - For example: `ops 2.3.12 Bug fixes for the Juju foobar feature when using Python 3.12` + For example: `2.3.12 Bug fixes for the Juju foobar feature when using Python 3.12` 5. If the last release was for both `ops` and `ops-scenario`, leave the previous tag choice on `auto`. If the last release was for only one package, change the previous tag to be the last time the same package(s) were being released. From 1be234a908d2a67b1f5bf6dbf40ea36aae1e066f Mon Sep 17 00:00:00 2001 From: Dave Wilding Date: Fri, 29 Nov 2024 09:55:18 +0800 Subject: [PATCH 4/5] changed order of steps to match GitHub UI --- HACKING.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/HACKING.md b/HACKING.md index 7b84d0312..6903d3c35 100644 --- a/HACKING.md +++ b/HACKING.md @@ -330,12 +330,12 @@ To make a release of the `ops` and/or `ops-scenario` packages, do the following: in the form `.. and ops[testing] ..` and a brief summary of the main changes in the release. For example: `2.3.12 Bug fixes for the Juju foobar feature when using Python 3.12` -5. If the last release was for both `ops` and `ops-scenario`, leave the previous - tag choice on `auto`. If the last release was for only one package, change - the previous tag to be the last time the same package(s) were being released. -6. Have the release create a new tag, in the form `..` for +5. Have the release create a new tag, in the form `..` for `ops` and `scenario-..` for `ops-scenario`. If releasing both packages, use the ops tag. +6. If the last release was for both `ops` and `ops-scenario`, leave the previous + tag choice on `auto`. If the last release was for only one package, change + the previous tag to be the last time the same package(s) were being released. 7. Use the "Generate Release Notes" button to get a copy of the changes into the notes field. The 'Release Documentation' section below details the form that the release notes and changelog should take. From 55ee744d3d09b8464d0bfb1309530ee2da755011 Mon Sep 17 00:00:00 2001 From: Dave Wilding Date: Tue, 3 Dec 2024 08:55:40 +0800 Subject: [PATCH 5/5] reverted format for release title --- HACKING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/HACKING.md b/HACKING.md index 6903d3c35..8424b2eb1 100644 --- a/HACKING.md +++ b/HACKING.md @@ -327,7 +327,7 @@ To make a release of the `ops` and/or `ops-scenario` packages, do the following: 2. Visit the [releases page on GitHub](https://github.com/canonical/operator/releases). 3. Click "Draft a new release" 4. The "Release Title" is the full version numbers of ops and/or ops-scenario, - in the form `.. and ops[testing] ..` + in the form `ops .. and ops-scenario ..` and a brief summary of the main changes in the release. For example: `2.3.12 Bug fixes for the Juju foobar feature when using Python 3.12` 5. Have the release create a new tag, in the form `..` for