Release v2.0.1

[MikeAlhayek]

Prepare the project

Do some housekeeping on GitHub in the main repo.

• Assign the milestone of the release's version to this issue.
• Close remaining issues for the version (including merging corresponding pull requests if suitable) or assign them to the next one.
• Assign all issues that were closed for an upcoming version (including a wildcard version like "1.0.x") to this version (milestone).

Prepare the code and documentation

Update the source, so everything looks like on the new version.

• Create a release/<version name> branch (e.g., release/1.8.0) from main or the previous release branch. This is necessary to target pull requests for the upcoming release.
• Create an issue branch out of this branch as usual.
• Check the release_ci workflow is using the expected .NET version to build the Docker images.
• Update the OrchardCore.Commons.props file with <VersionSuffix></VersionSuffix> such that preview build numbers are not injected in packages. Verify the VersionPrefix tag matches the released version.
• Update module versions in src/OrchardCore/OrchardCore.Abstractions/Modules/Manifest/ManifestConstants.cs.
• Create a new milestone.
• Add final updates to the release notes in the documentation. It should include the following, at least:
  • Overview of the release's highlights and goals. What do you want people to remember this release for?
  • Prerequisites. What framework version do you need, anything else to work with Orchard?
  • Upgrade steps, any migration necessary from previous versions, and any breaking changes.
• Add the release notes documentation page to the documentation site's navigation in mkdocs.yml and remove it from not_in_nav.
• Update the documentation to mention the version in all places where the latest version is referenced, for example, but not limited to (do a search for the package version string): Status in the root README, CLI templates, commands, the Creating a new decoupled CMS Website guide.

Test the release

Make sure everything works all right.

• Make sure that OrchardCore.Samples works.
• Test the guides with the NuGet packages from the Cloudsmith feed (branches under release/ are automatically published too). Test at least the following guides:
  • Creating a modular ASP.NET Core application
  • Creating an Orchard Core CMS website
  • Creating a new decoupled CMS Website
• Re-certify Orchard Core for the latest major version of Red Hat Enterprise Linux if a new version has been released (e.g., v10 after v9). Refer to Orchard's Red Hat Ecosystem Catalog profile for the previously certified version, the Red Hat Customer Portal for the latest version, and our certification guide for the certification steps.

Prepare and publish Orchard Core Translations

Update everything in the Translations project. Only do this once all the code changes are done since localized strings can change until then.

• Update .po files with PoExtractor. This will also update Crowdin.
• Publish the new version on NuGet.
• Update the OrchardCore.Translations.All package reference in the main repo's ./Dependencies.Packages.props file to refer to the new NuGet package.

Publish the release

Do the harder parts of making the release public. This should come after everything above is done.

• Tag the head of release/<version name> with the version. Include v in the name, e.g. v1.8.0.
• Merge release/<version name> to main.
  • You'll need to create a pull request.
  • Merge it as a merge commit, not squash merge.
  • If there are merge conflicts, then create a release/<version name>-integration branch and fix them there.
• Create and publish a release on GitHub.
  • Generate release notes.
  • Add a link to the release notes in the docs (something like For details on this version see the [release notes in the documentation](link here).). Note that the docs will only be built once the branch is merged to main.
• Test the guides with the packages now automatically published to NuGet. Test at least the following guides:
  • Creating a modular ASP.NET Core application
  • Creating an Orchard Core CMS website
  • Creating a new decoupled CMS Website
• Update Try Orchard Core.

Publicize the release

Let the whole world know about our shiny new release. Savor this part! These steps will make the release public so only do them once everything else is ready.

• Tweet
• Post to the Orchard Core LinkedIn group
• Post to the Orchard Core Facebook page

After the release is done

• Create a new milestone with the next release number and close the old milestone.
• Create a new release notes documentation file for the next version in the OrchardCore.Docs project. (e.g., /releases/1.8.0.md). Don't add it to the docs navigation and exclude it from validation under not_in_nav with mkdocs.yml.
• Update the OrchardCore.Commons.props file with the next release number, and <VersionSuffix>preview</VersionSuffix> such that preview builds use the new one.

[MikeAlhayek]

I like to include the following into 2.0.1

#16777
#16774
#16757
#16753

[mvarblow]

@MikeAlhayek I just updated my site from 2.0.0 to 2.0.1 and am getting many new warmings/errors related to deprecated properties and methods. I would gladly be wrong about this, but... It appears that instead of just those 4 commits described in the release notes, 2.0.1 (the 2.0.0 release branch) includes everything from main as of 2 days ago?
3fd4202

CC @sebastienros @Piedone

[MikeAlhayek]

@mvarblow yes a wrong commit was done before the release which cause this issue. We are shipping 2.0.2 soon to address this issue.