1.3 Release

[sebastienros]

Prepare the project

Do some housekeeping on GitHub in the main repo.

• [x] Close remaining issues for the version (including merging corresponding pull requests if suitable) or assign then to the next one.
• [x] 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

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

• [x] Create a release/<version name> branch out of main.
• [x] Update code generation templates in OrchardCore.ProjectTemplates.
• [x] Update the OrchardCore.Commons.props file: Update VersionPrefix for release versions (like "1.0.0") and VersionSuffix for pre-release versions (like "rc2", for the full version to be e.g. "1.0.0-rc2").
• [x] Update module versions in ManifestConstants.

Test the release

Make sure everything works all right.

• [x] Make sure that OrchardCore.Samples works.
• [x] 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

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.

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

Prepare the documentation

Update the docs so they contain information about the new release so once the release is out you'll just need to point to new information.

• [x] Create release notes in a specific documentation section. You can take the previous release notes as a template.
  • 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, breaking changes.
  • Full changelog. You can generate this with github-changelog with the changelog OrchardCMS OrchardCore <previous version> <current version> command, e.g. changelog OrchardCMS OrchardCore 1.0.0-rc1 1.0.0-rc2. Alternatively, you can use Antoine's app too.

Publish the release

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

• [x] Merge release/<version name> to master.
  • Merges to master need two approvals so you'll need to create a pull request.
  • Merge it as a merge commit, not squash merge.
• [x] Tag master with the full version name, including the prefix and suffix (e.g. "1.0.0-rc2").
• [x] 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
• [x] 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.

• [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.
• [x] Update the tagged release on GitHub: Change its title to something more descriptive (e.g. "Orchard Core 1.0.0 RC 2"), add a link in its description to the release notes in the documentation (something like For details on this version see the [release notes in the documentation](link here).). Add a link to this release under Status in the root README.
• [ ] Publish a blog post on the website.
• [ ] Ask to publish a blog post on DevBlogs.
• [ ] Ask to publish a blog post on .NET Foundation News.
• [x] Tweet

[ns8482e]

it's main now not master :)

[Piedone]

BTW since then, GitHub can generate pretty nice release notes with a click of a button between two tags: https://github.com/Lombiq/UI-Testing-Toolbox/releases/tag/v1.7.0 We could just use this instead of custom release notes in the docs. (But still with highlights and notes about breaking changes added, so everything that can't be auto-generated.)

[Piedone]

Shouldn't OrchardCore.ProjectTemplates reference 1.3.0? It now references 1.3.0-preview-16386.

[sebastienros]

GitHub can generate pretty nice release notes with a click of a button between two tags

This is what we use in the release notes, and what we copy in the md file

Shouldn't OrchardCore.ProjectTemplates

Oopsy!

[sebastienros]

I don't see the issue in NuGet.org, where should we look at ?

[Piedone]

It's there. If you download the OrchardCore.ProjectTemplatespackage in e.g. content\OrchardCore.Templates.Cms.Module.template.config\template.json you'll see:

    "OrchardVersion": {
      "type": "parameter",
      "datatype": "string",
      "description": "Specifies which version of Orchard Core packages to use.",
      "replaces": "$(TemplateOrchardPackageVersion)",
      "defaultValue": "1.3.0-preview-16386"
    }

[sebastienros]

Ok, will fix the issue template too then, not precise enough. Will try to update the package with 1.3.0.1, and update the doc to use this version. I want to prevent a 1.3.1 just for that, there might be other things to fix we find soon.

[agriffard]

https://www.nuget.org/packages/OrchardCore.ProjectTemplates/1.2.2 had: "defaultValue": "1.2.2-preview-16385"

[Piedone]

I have to admit that I noticed that too but didn't bring it up :(.

[sebastienros]

Ok, let's fix it and just update the doc to force the value to 1.3.0 in the arguments. I am also updating the checklist so it doesn't get unnoticed next time.

[sebastienros]

There is nothing to update in the templates, it should have used the build number automatically. I think there might be an issue with the build order.

[sebastienros]

I think it's related to this:

dotnet pack is forced with 1.3.0 (the release tag) but the build number might still be the same as for the preview builds, an incremental value. In this workflow we should set it to a fix number too I guess.

[sebastienros]

Found the reason and the solution. We are generating the BuildNumber property as I mentioned in the previous post. But it's fine. What is necessary is to remove the VersionSuffix value (currently preview) and this won't be appended to the metadata:

AssemblyFileVersion:1.3.0.0
AssemblyInformationalVersion:1.3.0-preview-16386+62eed89890b6b9b6d71a02e1465269b9bb512207

[sebastienros]

This PR makes it clear for next release https://github.com/OrchardCMS/OrchardCore/pull/11351

Users can add --orchard-version 1.3.0 on project templates for now. We'll remove the note with next release.

[ns8482e]

1.3 doesn't support .netcoreapp3.1 or .net5 so It would be nice if we have that added in issue title / in readme

[Skrypt]

Create a new milestone 1.4