Release v2.1.6

[Piedone]

Release Patch Preparation Guide

Step 1: Backporting Pull Requests

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.
2. Backport Pull Requests: For PRs merged into the main branch that need to be applied to the release branch (e.g., release/2.1.x), comment on the merged PR with /backport to release/2.1.x. This comment will trigger a GitHub Action to create a new PR with the same changes for the release/2.1.x branch.
3. Merge PRs: Once all necessary PRs are created, merge them into the release/2.1.x branch.

Step 2: Code and Documentation Updates

• From the release branch (e.g., release/2.1.x), 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 for an example. Version Updates Checklist:
  • Update OrchardCore.Commons.props: Set <VersionSuffix></VersionSuffix> to the new version you're preparing for release.
  • Update Module Versions: Modify src/OrchardCore/OrchardCore.Abstractions/Modules/Manifest/ManifestConstants.cs to reflect the new version.
  • Release Notes: Finalize the 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.
• Create a version PR titled Release <version number (e.g., Release 2.1.1) from the version branch (e.g., release/2.1.1) into the release branch (e.g., release/2.1.x)
• In GitHub, manually run the Preview - CI workflow on your branch (NOT main). This will release a new preview version on Cloudsmith for testing.

Step 3: Validation

• Check Functionality: Update OrchardCore.Samples to the latest preview version generated in the previous step. Ensure the samples work as expected.
• 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
• If everything looks good and all checks pass, merge the version PR.

Step 4: Creating the 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 the release branch (e.g., release/2.1.x).
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 5: Aligning Branches

Merge to main: After releasing the new version, merge the release branch into the main branch to ensure main contains all administrative changes.

• Create a pull request from the release branch (e.g., release/2.1.x) into main.
• Resolve any merge conflicts using external tools (e.g., Fork) to avoid auto-merging main into the release branch. Important: DO NOT resolve conflicts using GitHub's interface; that will automatically merge main into the release branch, which must be avoided.
• Merge the PR if all checks pass. Don't delete the branch.

Step 6: Housekeeping

• Assign the milestone for the release version to this issue. Create one if it doesn't exist.
• Assign the milestone to the issues that were released in the version.
• Close the milestone.

Step 7: Publicizing the Release

• Post about the release on X (formerly Twitter) via the Orchard Core X (Twitter) repo.
• Post in the Orchard Core LinkedIn group.
• Share on the Orchard Core Facebook page.

[github-actions]

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.