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.

[sarahelsaig]

I'm close to the end now. We need this before the 2.0 release: #16580
I'm also investigating another strange behavior, but I'm not sure if that's related to OC yet. I will follow up with updates later today or tomorrow. EDIT: described the strange behavior in #16585.

[sarahelsaig]

@MikeAlhayek Good news, we are done testing with DotNest.

[MikeAlhayek]

@sarahelsaig that is great news! Do you want to tackle #16585 ?

[sarahelsaig]

@sarahelsaig that is great news! Do you want to tackle #16585 ?

I did it here: #16623.

[Piedone]

Nothing else remaining here before release, right?

[MikeAlhayek]

I like to take #16636 and #16614 in 2.0 since both has a breaking change.

[hishamco]

Nothing else remaining here before release, right?

I need to update PO Extract tool as well

Can we expect OC 2.0.0 to be released within 1-2 weeks? If Yes I will do the update ASAP

[MikeAlhayek]

The plan is to release OC early next week. So feel free to update the translations.

[hishamco]

IMHO we could do it in the OC Harvest :) meanwhile, we can test the latest fixes and check the translations, and integrations. Also OC Commerce and DotNest could do a final check before releae

[MikeAlhayek]

We want to release it before so we can talk about it and about 3.0 during the harvest.

[hishamco]

we can talk about it and about 3.0 during the harvest.

I'm not sure in which session we can talk about the current and future releases

[MikeAlhayek]

Probably during Q/A or side chats. I also think it's part of the keynote we are mentioning 3.0

[MikeAlhayek]

@agriffard can you please release translations package for 2.0.0?

[hishamco]

Can we hold for 1-2 days I need to bump PO Extractor update then @agriffard can release translation packages for 2.0.0

[MikeAlhayek]

@hishamco tomorrow by noon PST, we'll need to release 2.0. I hope you'll be done by then. Since the Harvest is next week, some people will be out and/or busy. So we can't wait much longer.

[hishamco]

Let us wait for @agriffard, if the current PO Extractor version is fine I will defer bumping the new version after 2.0.0. I don't like to harry up without proper testing

[agriffard]

I updated the translations last week: OrchardCMS/OrchardCore.Translations@0bb805e

I checked this task:
`Update .po files with PoExtractor. This will also update Crowdin.

I am not doing anything more.
I am not the one that usually does the 2 remaining tasks related to translations when we do a release:

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. 

[hishamco]

@sebastienros could you please handle this or shall one of us do it?

[MikeAlhayek]

@agriffard Is this the version we should be using then? https://cloudsmith.io/~orchardcore/packages/?q=version%3A1.0.1-beta-20060

Shouldn't we call this version 2.0.0-preview to match OC versions?

[agriffard]

@agriffard Is this the version we should be using then? https://cloudsmith.io/~orchardcore/packages/?q=version%3A1.0.1-beta-20060

I made an update with the latest changes.
Yes, The date seems to match the moment I pushed.

Shouldn't we call this version 2.0.0-preview to match OC versions?

I don't know where this version of OC.Translations in preview is set.

[MikeAlhayek]

@sebastienros could you please handle this or shall one of us do it?

@hishamco what are you asking here?

Are we still waiting on you to make any changes to the OrchardCore.Translations.All project or are the changes all done? If you are done, I can resume with the 2.0.0 release.

[hishamco]

What I mean is to publish the OC.Translations.All, seems @sebastienros was doing that each time

[MikeAlhayek]

@hishamco every commit on that project generates a new translation package. I can release a production version tomorrow "if you finished everything you want to do".

[MikeAlhayek]

I am going to delay this until Monday/Tuesday. We have one report of a 2.0 bug that we are still working on and we'll give people time to test the last changes over the weekend. Any objections?

[Piedone]

Go ahead!

[hishamco]

@hishamco every commit on that project generates a new translation package. I can release a production version tomorrow "if you finished everything you want to do".

I defer everything after 2.0.0 to avoid regression because we have limited time

[MikeAlhayek]

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.

@Piedone is it time to do this yet?

[Piedone]

It's still on 9.x so I don't think so.