Releases in Fantomas are not automated and require some manual steps by the maintainers.
The CHANGELOG.md needs a new header with an official release tag:
It is custom to have the next version merged into the
main branch and locally publish from there.
Verify that all recent PRs and closed issues are listed in the changelog. Normally, this should be ok as we require a changelog entry before we merge a PR.
To publish the new versions to NuGet:
dotnet fsi build.fsx --push
--push will try and publish the
*.nupkg files created by the build in the
Fantomas.Client will be excluded and requires a specific pipeline to publish.
The pipeline does assume that the
NUGET_KEY environment variable is set with a valid NuGet key.
A new GitHub release entry should be created for official versions. This will notify users who have subscribed to releases.
In the past some alpha or beta releases have had a GitHub release, it depends on the occasion.
Create a new tag based on the main branch. The assumption is that the
CHANGELOG file contains the tag version you are about to create.
For a revision release you can use the current date (example:
October 13th Release), for a minor or major releas pick the month name (example:
Some parts of the description are fixed, some depend on the occasions:
The format of the title is
# version (example:
# 5.0.5). This differs from the notation used in the changelog file!
For minors and majors a codename (inside a
<sub> tag) is used. All codenames so far have been song titles by the band Ghost (example
# 5.1.0 <sub>Kaisarion</sub> - 11/2022).
With the exception of
v5, "Get Back".
The list of people to thank is compiled by cross referencing the changelog entries. The author of the GitHub release is omitted.
Don't be shy to include other names of people who have contributed in alternative ways when the occasion calls for it.
*.nupkg files to the release artifacts.
Share the newly created release on our Discord server in the
Optionally share (minor or major) releases on other social media.