From 7d551c5ca4d3d17cfee86b023c338a069a2c7fb6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ina=20Od=C3=A9n=20=C3=96sterbo?= Date: Thu, 5 Jan 2023 12:22:07 +0100 Subject: [PATCH 1/5] new_release --- .github/pull_request_template.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 2991d8d72..dba7e246c 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -45,7 +45,7 @@ _"Breaking": The change will cause existing functionality to not work as expecte - [ ] Blocking PRs have been merged - [ ] Rebase / update of branch done -- [ ] PR to `master` branch (Product Owner / Scrum Master) +- [ ] PR to `master` branch (Product Owner / Scrum Master): Follow [the release instructions](../docs/procedures/new_release.md) - [ ] The [version](../dds_cli/version.py) is updated - [ ] I am bumping the major version (e.g. 1.x.x to 2.x.x) - [ ] I have made the corresponding changes to the API version From 440a1e9036921054228a32c592361b0d52b819f8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ina=20Od=C3=A9n=20=C3=96sterbo?= Date: Thu, 5 Jan 2023 12:22:20 +0100 Subject: [PATCH 2/5] new_release --- docs/procedures/new_release.md | 70 ++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 docs/procedures/new_release.md diff --git a/docs/procedures/new_release.md b/docs/procedures/new_release.md new file mode 100644 index 000000000..562c6997b --- /dev/null +++ b/docs/procedures/new_release.md @@ -0,0 +1,70 @@ +# How to create a new release + +1. Fork a new branch from `dev` +2. Update the version in [`version.py`](../../dds_cli/version.py) + - _Minor changes, e.g. bug fix_: Minor version upgrade, e.g. `1.0.1 --> 1.0.2` + - _Small changes, e.g. new feature_: Mid version upgrade, e.g. `1.1.0 --> 1.2.0` + - _Breaking changes or large new feature(s)_: Major version upgrade, e.g. `1.0.0 --> 2.0.0` +3. Push version change to branch +4. Run the `rich-codex` action [here](https://github.com/ScilifelabDataCentre/dds_cli/actions/workflows/rich-codex-cli.yml); Choose your current branch where it says "Run workflow" + - `rich-codex` will push changes to your branch; these commits _will not be signed_ + - In order for you to merge these changes into the `dev`/`master` branch, all commits need to be signed: + 1. Pull the changes to your local branch + 2. Run the following command: + ```bash + git rebase --exec 'git commit --amend --no-edit -n -S' dev + ``` + Git should now be signing all commits in this PR. + 3. Force push the newly signed commits + ```bash + git push --force + ``` +5. Create a new PR from `` to `dev` + 1. Verify that the new code example images look ok + 2. Wait for approval and merge by Product Owner or admin +6. Create a PR from `dev` to `master` + - All changes should be approved in the PRs to dev so reviewing the changes a second time in this PR is not necessary. Instead, the team should look through the code just to see if something looks weird. + - All sections and checks in the PR template should be filled in and checked. Follow the instruction in the PR description field. + - There should be at least one approval of the PR. + - _Everything looks ok and there's at least one approval?_ Merge it. + + > Documentation changes are automatically updated on GitHub pages when there's a push to `master`. However, in order to keep things consistent and to avoid confusion with the versions, always release a new version when changes are pushed to `master` (assuming all the changes have been verified) +7. [Draft a new release](https://github.com/ScilifelabDataCentre/dds_cli/releases) + 1. `Choose a tag` → `Find or create a new tag` → Fill in the new version, e.g. if the new version is `1.0.0`, you should fill in `v1.0.0`. + 2. `Target` should be set to `master` + 3. `Release title` field should be set to the same as the tag, e.g. `v1.0.0` + 4. `Write` → `Generate release notes`. + + You can also fill in something to describe what has been changed in this release, if you feel that the auto-generated release notes are missing something etc. + + 5. `Publish release`. + + A new version of the CLI will be published to [PyPi](https://pypi.org/project/dds-cli/) + +8. Verify that the new CLI version is updated on Uppmax + + Uppmax automatically upgrades the `dds-cli` version every day at midnight. Double-check that this has worked, if you have an Uppmax account. + + If there has been a major version change though and the CLI contains breaking changes, _Uppmax should be notified well in advance_ in order to plan for an upgrade at a specific time so that the users are blocked (automatic functionality in dds_web) for as short time as possible. + + ``` + [Recipient]: support@uppmax.uu.se + [Subject]: (Pavlin Mitev) Upgrade dds-cli module + + [Message]: + Hi, + + We will be releasing a new major version of the dds-cli on . The changes are breaking - would it be possible for you do a manual version upgrade at that time, so that the users don't experience issues? + + Thank you in advance! + ``` + +9. Inform users that there is a new version by adding a Message of the Day: `dds motd add` + + - If users do not upgrade the CLI when there is a new version, they may experience issues and errors. + - If there is a major version mismatch between the API and CLI (e.g. API version 1.0.0 and CLI version 2.0.0 or vice versa), the DDS will inform the users that they are blocked from using the DDS until they have upgraded. + - If there is no warning from the DDS and there is an error, the first thing they are asked to do in the troubleshooting documentation is to verify that the CLI version is correct. + + > Possible to have a procedure where we notify via email when there is a major version bump but only use the MOTD functionality if the version bump is mid / minor, but updating everytime we release a new version will only lead to the users ignoring the emails and therefore not getting the truly important information when they actually need it. + + From 39e3e4e17f11300f1279f5992c69f13abf9e2baa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ina=20Od=C3=A9n=20=C3=96sterbo?= Date: Thu, 5 Jan 2023 12:25:35 +0100 Subject: [PATCH 3/5] prettier --- docs/procedures/new_release.md | 97 +++++++++++++++++----------------- 1 file changed, 49 insertions(+), 48 deletions(-) diff --git a/docs/procedures/new_release.md b/docs/procedures/new_release.md index 562c6997b..015107e0c 100644 --- a/docs/procedures/new_release.md +++ b/docs/procedures/new_release.md @@ -2,69 +2,70 @@ 1. Fork a new branch from `dev` 2. Update the version in [`version.py`](../../dds_cli/version.py) - - _Minor changes, e.g. bug fix_: Minor version upgrade, e.g. `1.0.1 --> 1.0.2` - - _Small changes, e.g. new feature_: Mid version upgrade, e.g. `1.1.0 --> 1.2.0` - - _Breaking changes or large new feature(s)_: Major version upgrade, e.g. `1.0.0 --> 2.0.0` + - _Minor changes, e.g. bug fix_: Minor version upgrade, e.g. `1.0.1 --> 1.0.2` + - _Small changes, e.g. new feature_: Mid version upgrade, e.g. `1.1.0 --> 1.2.0` + - _Breaking changes or large new feature(s)_: Major version upgrade, e.g. `1.0.0 --> 2.0.0` 3. Push version change to branch 4. Run the `rich-codex` action [here](https://github.com/ScilifelabDataCentre/dds_cli/actions/workflows/rich-codex-cli.yml); Choose your current branch where it says "Run workflow" - - `rich-codex` will push changes to your branch; these commits _will not be signed_ - - In order for you to merge these changes into the `dev`/`master` branch, all commits need to be signed: - 1. Pull the changes to your local branch - 2. Run the following command: - ```bash - git rebase --exec 'git commit --amend --no-edit -n -S' dev - ``` - Git should now be signing all commits in this PR. - 3. Force push the newly signed commits - ```bash - git push --force - ``` + - `rich-codex` will push changes to your branch; these commits _will not be signed_ + - In order for you to merge these changes into the `dev`/`master` branch, all commits need to be signed: + 1. Pull the changes to your local branch + 2. Run the following command: + ```bash + git rebase --exec 'git commit --amend --no-edit -n -S' dev + ``` + Git should now be signing all commits in this PR. + 3. Force push the newly signed commits + ```bash + git push --force + ``` 5. Create a new PR from `` to `dev` - 1. Verify that the new code example images look ok - 2. Wait for approval and merge by Product Owner or admin + 1. Verify that the new code example images look ok + 2. Wait for approval and merge by Product Owner or admin 6. Create a PR from `dev` to `master` - - All changes should be approved in the PRs to dev so reviewing the changes a second time in this PR is not necessary. Instead, the team should look through the code just to see if something looks weird. - - All sections and checks in the PR template should be filled in and checked. Follow the instruction in the PR description field. - - There should be at least one approval of the PR. - - _Everything looks ok and there's at least one approval?_ Merge it. - > Documentation changes are automatically updated on GitHub pages when there's a push to `master`. However, in order to keep things consistent and to avoid confusion with the versions, always release a new version when changes are pushed to `master` (assuming all the changes have been verified) + - All changes should be approved in the PRs to dev so reviewing the changes a second time in this PR is not necessary. Instead, the team should look through the code just to see if something looks weird. + - All sections and checks in the PR template should be filled in and checked. Follow the instruction in the PR description field. + - There should be at least one approval of the PR. + - _Everything looks ok and there's at least one approval?_ Merge it. + + > Documentation changes are automatically updated on GitHub pages when there's a push to `master`. However, in order to keep things consistent and to avoid confusion with the versions, always release a new version when changes are pushed to `master` (assuming all the changes have been verified) + 7. [Draft a new release](https://github.com/ScilifelabDataCentre/dds_cli/releases) - 1. `Choose a tag` → `Find or create a new tag` → Fill in the new version, e.g. if the new version is `1.0.0`, you should fill in `v1.0.0`. - 2. `Target` should be set to `master` - 3. `Release title` field should be set to the same as the tag, e.g. `v1.0.0` - 4. `Write` → `Generate release notes`. - - You can also fill in something to describe what has been changed in this release, if you feel that the auto-generated release notes are missing something etc. - 5. `Publish release`. - - A new version of the CLI will be published to [PyPi](https://pypi.org/project/dds-cli/) + 1. `Choose a tag` → `Find or create a new tag` → Fill in the new version, e.g. if the new version is `1.0.0`, you should fill in `v1.0.0`. + 2. `Target` should be set to `master` + 3. `Release title` field should be set to the same as the tag, e.g. `v1.0.0` + 4. `Write` → `Generate release notes`. + + You can also fill in something to describe what has been changed in this release, if you feel that the auto-generated release notes are missing something etc. + + 5. `Publish release`. + + A new version of the CLI will be published to [PyPi](https://pypi.org/project/dds-cli/) 8. Verify that the new CLI version is updated on Uppmax - Uppmax automatically upgrades the `dds-cli` version every day at midnight. Double-check that this has worked, if you have an Uppmax account. + Uppmax automatically upgrades the `dds-cli` version every day at midnight. Double-check that this has worked, if you have an Uppmax account. - If there has been a major version change though and the CLI contains breaking changes, _Uppmax should be notified well in advance_ in order to plan for an upgrade at a specific time so that the users are blocked (automatic functionality in dds_web) for as short time as possible. + If there has been a major version change though and the CLI contains breaking changes, _Uppmax should be notified well in advance_ in order to plan for an upgrade at a specific time so that the users are blocked (automatic functionality in dds_web) for as short time as possible. - ``` - [Recipient]: support@uppmax.uu.se - [Subject]: (Pavlin Mitev) Upgrade dds-cli module - - [Message]: - Hi, + ``` + [Recipient]: support@uppmax.uu.se + [Subject]: (Pavlin Mitev) Upgrade dds-cli module - We will be releasing a new major version of the dds-cli on . The changes are breaking - would it be possible for you do a manual version upgrade at that time, so that the users don't experience issues? + [Message]: + Hi, - Thank you in advance! - ``` + We will be releasing a new major version of the dds-cli on . The changes are breaking - would it be possible for you do a manual version upgrade at that time, so that the users don't experience issues? -9. Inform users that there is a new version by adding a Message of the Day: `dds motd add` + Thank you in advance! + ``` - - If users do not upgrade the CLI when there is a new version, they may experience issues and errors. - - If there is a major version mismatch between the API and CLI (e.g. API version 1.0.0 and CLI version 2.0.0 or vice versa), the DDS will inform the users that they are blocked from using the DDS until they have upgraded. - - If there is no warning from the DDS and there is an error, the first thing they are asked to do in the troubleshooting documentation is to verify that the CLI version is correct. +9. Inform users that there is a new version by adding a Message of the Day: `dds motd add` - > Possible to have a procedure where we notify via email when there is a major version bump but only use the MOTD functionality if the version bump is mid / minor, but updating everytime we release a new version will only lead to the users ignoring the emails and therefore not getting the truly important information when they actually need it. - + - If users do not upgrade the CLI when there is a new version, they may experience issues and errors. + - If there is a major version mismatch between the API and CLI (e.g. API version 1.0.0 and CLI version 2.0.0 or vice versa), the DDS will inform the users that they are blocked from using the DDS until they have upgraded. + - If there is no warning from the DDS and there is an error, the first thing they are asked to do in the troubleshooting documentation is to verify that the CLI version is correct. + > Possible to have a procedure where we notify via email when there is a major version bump but only use the MOTD functionality if the version bump is mid / minor, but updating everytime we release a new version will only lead to the users ignoring the emails and therefore not getting the truly important information when they actually need it. From 22d486f9e03df8c69efe77ed6211e9eb75d10595 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ina=20Od=C3=A9n=20=C3=96sterbo?= Date: Thu, 5 Jan 2023 12:28:59 +0100 Subject: [PATCH 4/5] template update to clarify --- .github/pull_request_template.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index dba7e246c..ab51cc172 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -45,10 +45,10 @@ _"Breaking": The change will cause existing functionality to not work as expecte - [ ] Blocking PRs have been merged - [ ] Rebase / update of branch done -- [ ] PR to `master` branch (Product Owner / Scrum Master): Follow [the release instructions](../docs/procedures/new_release.md) - - [ ] The [version](../dds_cli/version.py) is updated - - [ ] I am bumping the major version (e.g. 1.x.x to 2.x.x) - - [ ] I have made the corresponding changes to the API version +- [ ] PR to `master` branch (Product Owner / Scrum Master) + - [ ] I have followed steps 1-5 in [the release instructions](../docs/procedures/new_release.md) + - [ ] I am bumping the major version (e.g. 1.x.x to 2.x.x) + - [ ] I have made the corresponding changes to the API version ## Checks From fc35943b666abbeb86f71a78dc9089357b769654 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ina=20Od=C3=A9n=20=C3=96sterbo?= Date: Thu, 5 Jan 2023 13:01:58 +0100 Subject: [PATCH 5/5] comment about breaking --- docs/procedures/new_release.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/procedures/new_release.md b/docs/procedures/new_release.md index 015107e0c..0722b63d9 100644 --- a/docs/procedures/new_release.md +++ b/docs/procedures/new_release.md @@ -2,9 +2,13 @@ 1. Fork a new branch from `dev` 2. Update the version in [`version.py`](../../dds_cli/version.py) + - _Minor changes, e.g. bug fix_: Minor version upgrade, e.g. `1.0.1 --> 1.0.2` - _Small changes, e.g. new feature_: Mid version upgrade, e.g. `1.1.0 --> 1.2.0` - _Breaking changes or large new feature(s)_: Major version upgrade, e.g. `1.0.0 --> 2.0.0` + + > Will break if Web / API version not bumped as well + 3. Push version change to branch 4. Run the `rich-codex` action [here](https://github.com/ScilifelabDataCentre/dds_cli/actions/workflows/rich-codex-cli.yml); Choose your current branch where it says "Run workflow" - `rich-codex` will push changes to your branch; these commits _will not be signed_