OrchardCMS
Release v2.0.0
Prepare the project
Do some housekeeping on GitHub in the main repo.
- [x] 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.
- [x] Create a
release/<version name>branch (e.g.,release/2.0.0) frommainor the previous release branch. This is necessary to target pull requests for the upcoming release. - [x] Create an issue branch out of this branch as usual.
- [x] Check the release_ci workflow is using the expected .NET version to build the Docker images.
- [x] Update the
OrchardCore.Commons.propsfile with<VersionSuffix></VersionSuffix>such that preview build numbers are not injected in packages. Verify theVersionPrefixtag matches the released version. - [x] Update module versions in
src/OrchardCore/OrchardCore.Abstractions/Modules/Manifest/ManifestConstants.cs. - [x] Create a new milestone.
- [x] Change the Orchard Core version in the project templates, more specifically in
dotnetcli.host.jsonandtemplate.jsonfiles. - [ ] 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.
- [x] Add the release notes documentation page to the documentation site's navigation in
mkdocs.ymland remove it fromnot_in_nav. - [x] 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.Samplesworks. - [ ] Test the guides with the NuGet packages from the Cloudsmith feed (branches under
release/are automatically published too). Test at least the following guides: - [ ] 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.Allpackage 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. Includevin the name, e.g.v2.0.0. - [ ] Merge
release/<version name>tomain.- 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>-integrationbranch 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 tomain.
- [ ] Test the guides with the packages now automatically published to NuGet. Test at least the following guides:
- [ ] Update Try Orchard Core.
After the release is done
- [ ] Create a new milestone with the next release number and close the old milestone.
- [x] Create a new release notes documentation file for the next version in the
OrchardCore.Docsproject. (e.g.,/releases/2.0.0.md). Don't add it to the docs navigation and exclude it from validation undernot_in_navwithmkdocs.yml. - [x] Update the
OrchardCore.Commons.propsfile 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
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 https://github.com/OrchardCMS/OrchardCore.Commerce/pull/454) and other solutions to the latest preview. Since the goalpost keeps moving with new issues discovered, this is far from straightforward.
@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.
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.
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.
@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?
I'll defer about the timing to Sári. However, this also depends on what changes go to OC in the meantime.
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.
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
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?
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
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
@hyzx86 @Piedone @hishamco please convert that into a discussion so we can keep this issue 2.0.0 release related only.
Thank you
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? https://github.com/OrchardCMS/OrchardCore/commit/a9122aea1a9bf4e138e63cadb86f258355f03504#diff-bc37d034bad564583790a46f19d807abfe519c5671395fd494d8cce506c42947R204
In this PR, I removed the exclusion rule so that we can track changes to the .template.config folders.
I don't feel like moving to GitHub Packages BTW, it seems like a pretty equivalent service.
@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?
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 https://github.com/OrchardCMS/OrchardCore/pull/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.
Note though that every breaking change like https://github.com/OrchardCMS/OrchardCore/pull/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?
This update should not need any code change. Rebuilding the project should be all one will need.
Great, then!
in there an rough ETA for DotNest?
Unless there are some new surprise breaking change, I will finish it in the next couple days.
The important point is that all of our current queries SqlQuery, Lucene Query and Graphql Query as well as the scripting extension executeQuery don't support totals so if we can't get these PRs done on the fly, can we start by defining these api's as returning an object rather than a collection?
link :https://github.com/OrchardCMS/OrchardCore/pull/11159
The important point is that all of our current queries
SqlQuery,Lucene QueryandGraphql Queryas well as the scripting extensionexecuteQuerydon't support totals so if we can't get these PRs done on the fly, can we start by defining these api's as returning an object rather than a collection?
@hyzx86 is this comment related to the release process of 2.0? Maybe you meant to post that on a different issue.
This issue is strictly for releasing 2.0 not with issues that could be related to 2.0. If you have an issue with 2.0, please open a new issue and we'll tag it with 2.0 milestone.
The important point is that all of our current queries
SqlQuery,Lucene QueryandGraphql Queryas well as the scripting extensionexecuteQuerydon't support totals so if we can't get these PRs done on the fly, can we start by defining these api's as returning an object rather than a collection?@hyzx86 is this comment related to the release process of 2.0? Maybe you meant to post that on a different issue.
This issue is strictly for releasing 2.0 not with issues that could be related to 2.0. If you have an issue with 2.0, please open a new issue and we'll tag it with 2.0 milestone.
I mean these tweaks will need to introduce some disruptive updates, and since we've already done some disruptive upgrades in 2.0
@hyzx86 Then please open a separate issue with any issue/concerns you may have with the current state of main.