You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Update the source so everything looks like on the new version.
Create a release/<version name> branch out of main, e.g. release/1.7.
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.
Update the version in the command lines in from all documentation files.
Test the guides with the NuGet packages from the Cloudsmith feed (branches under release/1.7 are automatically published too). Test at least the following guides:
If there's a more recent major version of Red Hat Enterprise Linux (like v10 after v9) that Orchard Core was certified for, then re-certify it. See Orchard's Red Hat Ecosystem Catalog profile for the version it was certified for, the Red hat Customer Portal for the latest released version, and [https://docs.orchardcore.net/en/latest/docs/topics/red-hat-ecosystem-catalog-certification/](our certification guide) for the steps to renew the certification.
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 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.
Create a new Draft Release with a tag vx.y.z that is created when the release is published. Auto-generate release notes.
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.
Publish the release
Do the harder parts of making the release public. This should come after everything above is done.
Merge release/<version name> to main.
Merges to main need two approvals so you'll need to create a pull request.
Merge it as a merge commit, not squash merge.
Publish the Draft release.
Test the guides with the packages now automatically published to NuGet. Test at least the following guides:
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.
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.
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.
Prepare the project
Do some housekeeping on GitHub in the main repo.
Prepare the code
Update the source so everything looks like on the new version.
release/<version name>
branch out ofmain
, e.g.release/1.7
.OrchardCore.Commons.props
file with<VersionSuffix></VersionSuffix>
such that preview build numbers are not injected in packages. Verify theVersionPrefix
tag matches the released version.src/OrchardCore/OrchardCore.Abstractions/Modules/Manifest/ManifestConstants.cs
.Test the release
Make sure everything works all right.
OrchardCore.Samples
works.release/1.7
are automatically published too). Test at least the following guides: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.
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.
vx.y.z
that is created when the release is published. Auto-generate release notes.Publish the release
Do the harder parts of making the release public. This should come after everything above is done.
release/<version name>
tomain
.main
need two approvals so you'll need to create a pull request.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.
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.The text was updated successfully, but these errors were encountered: