Release v2.0.0

[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 "2.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/2.0.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.
• Change the Orchard Core version in the project templates, more specifically in dotnetcli.host.json and template.json files.
• 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. v2.0.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.

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/2.0.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.

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

[MikeAlhayek]

We'll start this process after PR #16402 is merged.

[Piedone]

Don't do this yet, please. We had tons of regressions, the last one you discovered yesterday, so let's wait a bit to see if anything new will be discovered.

@sarahelsaig is also still working on upgrading Orchard Core Commerce (see OrchardCMS/OrchardCore.Commerce#454) and other solutions to the latest preview. Since the goalpost keeps moving with new issues discovered, this is far from straightforward.

[MikeAlhayek]

@Piedone yes no need to release this immediately. But as far as I know that @sarahelsaig has been working on this for a while now and found one bug only "which was fixed". So I assumed there was no additional bugs found. Either way, at some point we have to draw a line and just ship so we can allow wider audience to test the new release.

[sarahelsaig]

Actually I've found 11 bugs while testing with OCC and the Lombiq modules. The latest was fixed only 3 weeks ago. Also earlier this week I have found a new ISession concurrent access bug in OCC. I haven't opened an issue yet because I couldn't isolate the reproduction steps and it would not be a useful bug report without that.

[Piedone]

The point though is, having OCC and a few other large Lombiq solutions upgraded, and their over 300 UI tests passing, is a strong evidence that we're ready for a release. Otherwise, we'll have subsequent patch releases every other day.

This has been a really bumpy road, getting blocked repeatedly. Version 2 will be a very risky release, hence we had a huge amount of regressions reported. So, due to the lack of a comprehensive automated QA suite, this is our second-best bet to make sure it'll go well.

We can prevent further moving the goalposts by not merging anything else than bugfixes though.

[MikeAlhayek]

@Piedone Ideally we want Lombiq projects converted and all tests pass. But, will this happen any time soon? We just don't want to hold the release indefinitely without having some sort of plan to release. Is there a target finish date for Lombiq transition?

Actually I've found 11 bugs while testing with OCC and the Lombiq modules.

@sarahelsaig beside that ISession issue, are there any other issue from the 11 you reported that still need to be addressed?

[Piedone]

I'll defer about the timing to Sári. However, this also depends on what changes go to OC in the meantime.

[MikeAlhayek]

Once we have timeline, we'll be able to determine what will go into 2.0 and what will have to wait. But we should be looking into releasing 2.0 before August 1st as a max date. 1.8.0 was released in January 2, 2024. So we are well over due for a release.

[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.

[Piedone]

[MikeAlhayek]

Change the Orchard Core version in the project templates, more specifically in dotnetcli.host.json and template.json files.

@Piedone I think this line item you added to the to do list. Both dotnetcli.host.json and template.json are not tracked on Github. Why do we need these files? Should they be checked in?

[Piedone]

They are part of the templates:

[hyzx86]

Are there any drawbacks to gitub's nuget service?

[Piedone]

Do you mean GitHub Packages? It isn't free, unlike Cloudsmith.

[hishamco]

@Piedone I tried a long time ago without any cost

[Piedone]

I see, it's actually free for public packages: https://docs.github.com/en/billing/managing-billing-for-github-packages/about-billing-for-github-packages#about-billing-for-github-packages

[hishamco]

Yes it's, it might be suited for us, especially for nightly builds, the thing I suffered from at that time was referencing them, from another apps

[MikeAlhayek]

@hyzx86 @Piedone @hishamco please convert that into a discussion so we can keep this issue 2.0.0 release related only.

Thank you

[MikeAlhayek]

They are part of the templates:

@Piedone I think the issue is that these files are ignored from .gitignore I am not sure why these are ignored. @agriffard do you recall why this folder was ignore while the files are still on the server? a9122ae#diff-bc37d034bad564583790a46f19d807abfe519c5671395fd494d8cce506c42947R204

In this PR, I removed the exclusion rule so that we can track changes to the .template.config folders.

[Piedone]

I don't feel like moving to GitHub Packages BTW, it seems like a pretty equivalent service.

[MikeAlhayek]

@Piedone It looks like @sarahelsaig completed the migration of e-commerce project and everything is passing. Are there any other project that we should wait for before we resume the release of 2.0?

[Piedone]

Yeah, she's working on DotNest as well, which is a different kind of test with all the random people's tenants. Note though that every breaking change like #16493 necessitates another round of updates.

I'd also be a lot more confident if we can go a week without a regression being reported.

[MikeAlhayek]

Note though that every breaking change like #16493 necessitates another round of updates.

This update should not need any code change. Rebuilding the project should be all one will need.

I am okay with waiting a week to waiting. But the question, how long will the DotNest upgrade takes? @sarahelsaig in there an rough ETA for DotNest?

[Piedone]

This update should not need any code change. Rebuilding the project should be all one will need.

Great, then!

[sarahelsaig]

in there an rough ETA for DotNest?

Unless there are some new surprise breaking change, I will finish it in the next couple days.