[x] All issues in the assigned milestone are closed and all issue tasks are complete.
[x] Add 🚀Preview Release label to this issue.
[x] Issue is assigned to a project.
[x] Issue is assigned to a milestone.
[x] Release PR linked to this issue.
[x] All unit tests have been executed locally and have passed. (Check out the appropriate release branch before running tests).
[x] Version in project file updated (All changes made directly on the release branch (preview/v#.#.#-preview.#)).
[x] Release notes created and added (All changes made directly on the release branch (preview/v#.#.#-preview.#)).
[x] Manual QA Testing completed (if applicable).
[x] Pull request has been approved and merged into a release branch before performing the release. (Releases are performed on preview branches).
[x] Release to preview complete. (The release is performed by running the 🚀Preview Release workflow).
Post-Release ToDo List
[x] The GitHub release has been created and is correct.
[x] The NuGet package has been successfully deployed to nuget.org(if applicable).
[x] Announcement of release on Twitter verified (if applicable). (Announcement should be performed automatically with the release).
[x] Announcement has been pushed to the Discord channel (if applicable).
Additional Information:
Unit Tests
Reasons for local unit test execution:
Unit tests might pass locally but not in the CI environment during the status check process or vice-versa.
Tests might pass on the developer's machine but not necessarily on the code reviewer's machine.
Version Updating
The version can be updated by setting the values of the <Version/> and <FileVersion/> XML tags in the project file.
The <Version/> and <FileVersion/> values can hold production and preview releases.
The <AssemblyVersion/> XML tag can only hold production values. Preview values are not allowed.
By default, the release notes go into a ReleaseNotes folder inside of the Documentation folder with the Documentation folder at the root of the repository.
Preview release notes path: ./Documentation/ReleaseNotes/PreviewReleases.
Release note file names must follow a particular syntax and are in markdown format so they can be added to the release.
Release Notes File Name Syntax:
Preview Release Notes:
Syntax: Release-Notes-v#.#.#-preview.#.md
Example: Release-Notes-v1.2.3-preview.4.md
Changes such as release notes and version updates should be committed to the destination branch (preview/v#.#.#-preview.#) in the pull request attached to this issue.
Code of Conduct
[X] I agree to follow this project's Code of Conduct
Pre-Release ToDo List
🚀Preview Releaselabel to this issue.🚀Preview Releaseworkflow).Post-Release ToDo List
Additional Information:
Unit Tests
Reasons for local unit test execution:
Version Updating
The version can be updated by setting the values of the
<Version/>and<FileVersion/>XML tags in the project file. The<Version/>and<FileVersion/>values can hold production and preview releases. The<AssemblyVersion/>XML tag can only hold production values. Preview values are not allowed.Release Notes
By default, the release notes go into a ReleaseNotes folder inside of the Documentation folder with the Documentation folder at the root of the repository. Preview release notes path: ./Documentation/ReleaseNotes/PreviewReleases.
Release note file names must follow a particular syntax and are in markdown format so they can be added to the release.
Release Notes File Name Syntax:
Changes such as release notes and version updates should be committed to the destination branch (preview/v#.#.#-preview.#) in the pull request attached to this issue.
Code of Conduct