Updating release instructions (Lombiq Technologies: OCORE-223) #17499

Piedone · 2025-02-20T01:35:08Z

Summary:

Aligned the instructions with what we've actually been doing.
Whitespace fixes.
I'd name the release branches as 2.1.x instead of 2.1 to signify that it's not only for 2.1.0.
Unified the same steps across the patch and other instructions.

The #17496 issue shows most of this in action, but I adjusted the template even after that.

.github/ISSUE_TEMPLATE/patch_release.md

MikeAlhayek

We no longer use patch version in a release branch. All of our release branches are major.minor only. Please keep it as it was major.minor.

.github/ISSUE_TEMPLATE/patch_release.md

MikeAlhayek · 2025-02-20T03:58:44Z

.github/ISSUE_TEMPLATE/patch_release.md

-  - [ ] Create a **Documentation PR** titled "Release with the new version number" (e.g., `Release 2.1.1`) from the documentation branch (e.g., `release-notes/2.1.1`) into the release branch (e.g., `release/2.1`)
-  - [ ] Merge the Documentation PR.
-  - [ ] In GitHub, manually run the `Preview - CI` workflow on your branch (NOT `main`). This will release a new preview version on CloudSmith for testing.
+- [ ] From the release branch (e.g., `release/2.1.x`), create a new temporary branch for the version (e.g., `release/2.1.1`).


Suggested change

- [ ] From the release branch (e.g., `release/2.1.x`), create a new temporary branch for the version (e.g., `release/2.1.1`).

- [ ] From the release branch (e.g., `release/2.1`), create a new temporary branch for the version (e.g., `release/2.1`).

The second branch name is for the patch release. It's deleted after completing it. Previously, the guide contained release-notes/2.1.1 for the same.

.github/ISSUE_TEMPLATE/patch_release.md

MikeAlhayek · 2025-02-20T03:59:50Z

.github/ISSUE_TEMPLATE/patch_release.md

+- [ ] Merge the PR if all checks pass. If there are merge conflicts, then you'll need to merge to `main` manually using the following steps:
+  1. Fetch the latest changes from the Git repository.
+  2. Checkout the `main` branch.
+  3. Merge the release branch (e.g., `release/2.1.x`) into `main` with a merge commit (NOT a squash merge).


Suggested change

3. Merge the release branch (e.g., `release/2.1.x`) into `main` with a merge commit (NOT a squash merge).

3. Merge the release branch (e.g., `release/2.1`) into `main` with a merge commit (NOT a squash merge).

Name it something like "Merge release/2.1 into main"

.github/ISSUE_TEMPLATE/release.md

Co-authored-by: Mike Alhayek <[email protected]>

MikeAlhayek · 2025-02-20T23:33:29Z

.github/ISSUE_TEMPLATE/patch_release.md

-  - [ ] Create a **Documentation PR** titled "Release with the new version number" (e.g., `Release 2.1.1`) from the documentation branch (e.g., `release-notes/2.1.1`) into the release branch (e.g., `release/2.1`)
-  - [ ] Merge the Documentation PR.
-  - [ ] In GitHub, manually run the `Preview - CI` workflow on your branch (NOT `main`). This will release a new preview version on CloudSmith for testing.
+- [ ] From the release branch (e.g., `release/2.1`), create a new temporary branch for the version (e.g., `release/2.1.1`).


Suggested change

- [ ] From the release branch (e.g., `release/2.1`), create a new temporary branch for the version (e.g., `release/2.1.1`).

- [ ] From the release branch (e.g., `release/2.1`), create a new temporary branch for the version (e.g., `release-notes/2.1.1`).

This was purposely set to release-notes to distinguish the docs branches from an actual release branch.

But it's not just about the release notes. There are other preparations as well, that the guide included already (changing the version numbers in the code, updating the guides), that need to happen in some branch and shouldn't happen directly in the release one.

yes but these are all administrative changes. I am fine with release-notes, if you want to change it, please change it to something other than release this way we don't confuse it with an actual release branch.

release-prep?

That's in the template now.

.github/ISSUE_TEMPLATE/patch_release.md

.github/ISSUE_TEMPLATE/release.md

MikeAlhayek · 2025-02-20T23:43:16Z

.github/ISSUE_TEMPLATE/release.md


-## Step 6: Post-Release Tasks
+## Step 7: Post-Release Tasks


If you like the ing, the would Be Posting Release Tasks but I don't like the ing :)

@Piedone this one?

Not sure what you mean, sorry. If you mean this I left out: isn't this answered by #17499 (comment)?

Co-authored-by: Mike Alhayek <[email protected]>

hishamco · 2025-02-22T03:58:12Z

.github/ISSUE_TEMPLATE/patch_release.md

@@ -11,67 +11,71 @@ assignees: ''

 ## Step 1: Backporting Pull Requests

-1. **Identify Pull Requests**: Review any pull requests (PRs) that need to be backported to the release branch.
-2. **Backporting Process**: For PRs merged into the `main` branch that need to be applied to the release branch (e.g., `release/2.1`), comment on the merged PR with `/backport to release/2.1`. This comment will trigger a GitHub Action to create a new PR with the same changes for the `release/2.1` branch.
+1. **Identify Pull Requests**: Review any pull requests (PRs) that need to be backported to the release branch. These should be PRs that contain strictly bug fixes and nothing else.


Suggested change

1. **Identify Pull Requests**: Review any pull requests (PRs) that need to be backported to the release branch. These should be PRs that contain strictly bug fixes and nothing else.

1. **Identify Pull Requests**: Review any pull requests (PRs) that need to be backported to the release branch. These should be PRs that contain strict bug fixes and nothing else.

This would mean that the bug fixes are strict. But the original is neither correct, should be "strictly contain...".

hishamco · 2025-02-22T03:59:06Z

.github/ISSUE_TEMPLATE/patch_release.md

-  - [ ] Merge the Documentation PR.
-  - [ ] In GitHub, manually run the `Preview - CI` workflow on your branch (NOT `main`). This will release a new preview version on CloudSmith for testing.
+- [ ] From the release branch (e.g., `release/2.1`), create a new temporary branch for the version (e.g., `release/2.1.1`).
+- [ ] Update version references in the documentation and code. Refer to [this PR](https://github.com/OrchardCMS/OrchardCore/pull/17065/files) for an example. The easiest is to start with a search & replace on the previous version. Version Updates Checklist:


Suggested change

- [ ] Update version references in the documentation and code. Refer to [this PR](https://github.com/OrchardCMS/OrchardCore/pull/17065/files) for an example. The easiest is to start with a search & replace on the previous version. Version Updates Checklist:

- [ ] Update version references in the documentation and code. Refer to [this PR](https://github.com/OrchardCMS/OrchardCore/pull/17065/files) for an example. The easiest is to start with a search & replace the previous version. Version Updates Checklist:

Something needs to be between "search & replace" and "the previous version". I refined it a bit.

.github/ISSUE_TEMPLATE/patch_release.md

.github/ISSUE_TEMPLATE/release.md

Co-authored-by: Hisham Bin Ateya <[email protected]>

.github/ISSUE_TEMPLATE/patch_release.md

Co-authored-by: Hisham Bin Ateya <[email protected]>

Piedone added 2 commits February 20, 2025 02:29

Updating release instructions

89f6d90

Formatting merge steps

4b181e5

Piedone requested a review from MikeAlhayek February 20, 2025 01:36

You only need to set VersionSuffix

9c39dc1

Piedone commented Feb 20, 2025

View reviewed changes

.github/ISSUE_TEMPLATE/patch_release.md Show resolved Hide resolved

MikeAlhayek requested changes Feb 20, 2025

View reviewed changes

Piedone and others added 4 commits February 20, 2025 22:08

Adding notes about the merge commits

fbb5091

Removing the unused thanks issue template

fb5fa04

Reverting wildcard patch version in branch names

b1563fe

Co-authored-by: Mike Alhayek <[email protected]>

Reverting more

1219225

Piedone requested review from sebastienros and MikeAlhayek February 20, 2025 21:14

MikeAlhayek reviewed Feb 20, 2025

View reviewed changes

Typo

e5a3a45

Co-authored-by: Mike Alhayek <[email protected]>

hishamco requested changes Feb 22, 2025

View reviewed changes

Piedone and others added 7 commits February 22, 2025 05:30

Grammar

0f15316

More grammar

19ad509

Grammar

b009292

Co-authored-by: Hisham Bin Ateya <[email protected]>

Grammar

25d56d1

Even more grammar

b346e3a

Co-authored-by: Hisham Bin Ateya <[email protected]>

release-prep

afe5e2d

Grammar

f865e96

hishamco requested changes Feb 23, 2025

View reviewed changes

.github/ISSUE_TEMPLATE/patch_release.md Outdated Show resolved Hide resolved

Grammar

cb3dec9

Co-authored-by: Hisham Bin Ateya <[email protected]>

Piedone requested review from hishamco and MikeAlhayek February 23, 2025 16:24

hishamco approved these changes Feb 23, 2025

View reviewed changes

MikeAlhayek approved these changes Feb 23, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Updating release instructions (Lombiq Technologies: OCORE-223) #17499

Updating release instructions (Lombiq Technologies: OCORE-223) #17499

Piedone commented Feb 20, 2025

MikeAlhayek left a comment

MikeAlhayek Feb 20, 2025

Piedone Feb 20, 2025

MikeAlhayek Feb 20, 2025

sebastienros Feb 20, 2025

MikeAlhayek Feb 20, 2025

Piedone Feb 21, 2025

MikeAlhayek Feb 22, 2025

Piedone Feb 22, 2025

MikeAlhayek Feb 22, 2025

Piedone Feb 22, 2025

MikeAlhayek Feb 20, 2025

MikeAlhayek Feb 22, 2025

Piedone Feb 22, 2025

hishamco Feb 22, 2025

Piedone Feb 22, 2025

hishamco Feb 22, 2025

Piedone Feb 22, 2025

	- [ ] From the release branch (e.g., `release/2.1.x`), create a new temporary branch for the version (e.g., `release/2.1.1`).
	- [ ] From the release branch (e.g., `release/2.1`), create a new temporary branch for the version (e.g., `release/2.1`).

	3. Merge the release branch (e.g., `release/2.1.x`) into `main` with a merge commit (NOT a squash merge).
	3. Merge the release branch (e.g., `release/2.1`) into `main` with a merge commit (NOT a squash merge).

	1. Identify Pull Requests: Review any pull requests (PRs) that need to be backported to the release branch. These should be PRs that contain strictly bug fixes and nothing else.
	1. Identify Pull Requests: Review any pull requests (PRs) that need to be backported to the release branch. These should be PRs that contain strict bug fixes and nothing else.

	- [ ] Update version references in the documentation and code. Refer to [this PR](https://github.com/OrchardCMS/OrchardCore/pull/17065/files) for an example. The easiest is to start with a search & replace on the previous version. Version Updates Checklist:
	- [ ] Update version references in the documentation and code. Refer to [this PR](https://github.com/OrchardCMS/OrchardCore/pull/17065/files) for an example. The easiest is to start with a search & replace the previous version. Version Updates Checklist:

Updating release instructions (Lombiq Technologies: OCORE-223) #17499

Are you sure you want to change the base?

Updating release instructions (Lombiq Technologies: OCORE-223) #17499

Conversation

Piedone commented Feb 20, 2025

MikeAlhayek left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment