Release v2.1.2

[MikeAlhayek]

Release Patch Preparation Guide

Step 1: Backporting Pull Requests

1. Identify PRs: 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 release/2.1, comment on the merged PR with /backport to release/2.1. This action will trigger GitHub to create a new PR with the same changes for the release/2.1 branch.
3. Merge PRs: Once all necessary PRs are created, merge them into the release/2.1 branch.

Step 2: Administration Tasks

Create Pull Request:

• From the release branch (e.g., release/2.1), create a new branch for your release (e.g., release-notes/2.1.1).
• Update version references in the documentation. Refer to this PR for an example.
• Version Updates Checklist:
  • Update OrchardCore.Commons.props: Set <VersionSuffix></VersionSuffix> to prevent preview build numbers. Ensure VersionPrefix matches the released version.
  • Update Module Versions: Modify src/OrchardCore/OrchardCore.Abstractions/Modules/Manifest/ManifestConstants.cs as needed.
  • Release Notes: Finalize release notes in the documentation, including:
    • Highlights and goals of the release.
    • Prerequisites for running the new version.
    • Upgrade steps and any breaking changes.
  • Update Documentation Navigation: Add the release notes page to mkdocs.yml navigation and remove it from not_in_nav.
  • Version Mentions: Update all references to the new version throughout the documentation, including:
    • Status in the root README
    • CLI templates and commands.
    • Relevant guides, such as the Creating a new decoupled CMS Website guide.

Step 3: Create New Release

1. Navigate to the GitHub Releases page.
2. In the "Choose a tag" menu, enter the new version number including v (e.g., v2.1.1) and select "+ Create tag: v... on publish."
3. Change the target branch from main to your target branch (e.g., release/2.1).
4. Enter the version number in the Title field (e.g., 2.1.1).
5. Click Generate release notes to auto-generate release notes.
6. Ensure the "Set as the latest release" checkbox is checked, then click Publish release.

Step 4: Align Branches

1. Merge to Main: After releasing the new version, merge the release branch into the main branch to ensure main contains all administration changes.
   • Create a pull request from the release branch into main.
   • Important: DO NOT resolve conflicts using GitHub's interface; use other tools (e.g., Fork) to manage conflicts and avoid auto-merging main into the release branch. Resolving conflicts using GitHub will automatically merge main into the release branch which MUST be avoided.
   • Once conflicts are resolved, merge the PR into main.

Step 5: Housekeeping

• Assign the milestone of the release version to the issue.
• Close any remaining issues for this version or assign them to the next release.

Step 6: Validation

1. Check Functionality: Ensure that the OrchardCore.Samples works as expected.
2. Test Guides: Test the following guides with NuGet packages from the Cloudsmith feed:
   • Creating a modular ASP.NET Core application
   • Creating an Orchard Core CMS website
   • Creating a new decoupled CMS Website

Step 7: Publicize the Release

1. Announce the new release:
   • Tweet using the Orchard-Core-X-Twitter project.
   • Post in the Orchard Core LinkedIn group.
   • Share on the Orchard Core Facebook page.

[Piedone]

I'm updating OSOCE and finding regressions. Please don't finalize the release until the important one of those are fixed and I can confirm with the preview packages that there are no outstandinf issues.

[MikeAlhayek]

@Piedone I think we need to ship v2.0.2 soon to to address the 3 issues that we know about. Do you see another immediate problem that is worth waiting for so can I ship this after merging #17087?

[Piedone]

I don't yet, but I've spent half a day on this update and I'm bogged down with other things that need to be fixed due to the Site Owner deprecation. I'll be able to tell better tomorrow.

Please don't publish a release yet. With a high chance I'll find other breaking things, and having to publish patches every other day due to regressions sends a really bad message.

[MikeAlhayek]

@Piedone if you find no issues, please release 2.1.2 as I won't be available for the next few days to do the release myself.

[Piedone]

Sure.

[MikeAlhayek]

@Piedone I suggest that you release 2.1.2 (after merging #17087) no later than tomorrow to unbreak people. Then we can release 2.1.3 next week if needed with more fixes. There is a critical issue that is causing tenants not to run in 2.1.x and must be solved ASAP.

/cc: @sebastienros

[Piedone]

There is a critical issue that is causing tenants not to run in 2.1.x and must be solved ASAP.

What are you referring to? Because #17087 is not that.

[MikeAlhayek]

The critical issue is this: #17077

Which causes tenant not to run due to infinite loop

[Piedone]

Ah OK.

[Piedone]

I didn't find any other issues. @kevinchalet, if you can, please review #17087 and #17089 because you're much more competent in the topic than me, so we can merge those and do a release.

[kevinchalet]

@kevinchalet, if you can, please review #17087 and #17089 because you're much more competent in the topic than me, so we can merge those and do a release.

Done 👍🏻

[Piedone]

Thank you!

[MikeAlhayek]

@Piedone @domonkosgabor please shape on Facebook.

[Piedone]

Thanks for doing the release!

[MikeAlhayek]

@Piedone is there a reason why tests like the only you run in other projects are not in OC project instead? Moving all these tests to OC will help us catching issue early on instead of having to wait for others to upgrade.

[Piedone]

I actually implemented a test suite for OC in the same way (not all features, but a lot more than the current functional tests) but there was no interest: #11194

The tests in the Lombiq solutions are complementary BTW, since those only test Lombiq extensions. Those, however, can also bring out regressions and unwanted breaking changes.

[MikeAlhayek]

Some tests can be brought to OC without beginning everything else. For example, the test that tests the API to create tenant or create or retrieve content using the API.

[Piedone]

It can be started small and focused, but that would still need reinventing the wheel, and step by step it would need solving the same problems again, even for a single test, let alone if there are two or more. I find that pointless and I would definitely not work on it myself.