Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 1.5 #12680

Closed
18 of 22 tasks
Skrypt opened this issue Oct 21, 2022 · 6 comments · Fixed by #12635
Closed
18 of 22 tasks

Release 1.5 #12680

Skrypt opened this issue Oct 21, 2022 · 6 comments · Fixed by #12635
Labels

Comments

@Skrypt
Copy link
Contributor

Skrypt commented Oct 21, 2022

Prepare the project

Do some housekeeping on GitHub in the main repo.

  • 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.
  • Update code generation templates in OrchardCore.ProjectTemplates.
  • 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").
  • Update module versions in ManifestConstants.

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 src/OrchardCore.Build/Dependencies.props file to refer to the new NuGet package.

Test the release

Make sure everything works all right.

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

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.

  • 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.
  • 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.
  • Tweet
@MikeAlhayek MikeAlhayek pinned this issue Oct 21, 2022
@agriffard
Copy link
Member

I set the dev branch to hidden yesterday.

@Skrypt Skrypt mentioned this issue Oct 27, 2022
@MikeAlhayek MikeAlhayek unpinned this issue Nov 5, 2022
@Skrypt
Copy link
Contributor Author

Skrypt commented Nov 8, 2022

Nlog configurations have changed and there is no indication about it in the release.md file. We should advise people that the NLog configs have changed so that it doesn't lead to overlogging for them.

https://github.com/NLog/NLog.Web/wiki/Missing-trace%5Cdebug-logs-in-ASP.NET-Core-6%3F

@deanmarcussen
Copy link
Member

Nlog configurations have changed and there is no indication about it in the release.md file. We should advise people that the NLog configs have changed so that it doesn't lead to overlogging for them.

https://github.com/NLog/NLog.Web/wiki/Missing-trace%5Cdebug-logs-in-ASP.NET-Core-6%3F

Also need to update the UseNLogWeb extensions to support passing an NLog config to enable the old behaviour.

Minor issue, but we tracked +1gb of logs this morning after deploying, because we rely on the aspnetcore logging section to reduce our log levels.

@Skrypt
Copy link
Contributor Author

Skrypt commented Nov 8, 2022

Well, it can become a bigger issue if the logs are filling the entire server storage. So, everyone should make sure to take a look before deploying.

@snakefoot
Copy link

snakefoot commented Nov 8, 2022

Also need to update the UseNLogWeb extensions to support passing an NLog config to enable the old behaviour.

It is also possible to overwite the default value using this static-property (apply before AddNLog / UseNLog):

NLog.Web.NLogAspNetCoreOptions.Default.RemoveLoggerFactoryFilter = false;

The recommended approach is just to fix the NLog-configuration like this:

<rules>
    <logger name="System.*" finalMinLevel="Warn" />    <!-- Insert at the top -->
    <logger name="Microsoft.*" finalMinLevel="Warn" /> <!-- Insert at the top -->

    <!-- Everything else -->
</rules>

See also: https://nlog-project.org/2021/08/25/nlog-5-0-preview1-ready.html#nlogextensionslogging-without-any-filter

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants