Creating a new release
- Make sure there are no outstanding commits or
pull requests that should be in the new release.
- Do some testing.
- Pick a release number
X.Y.Z
where X
, Y
, and Z
are numbers (no additional characters).
To stay consistent with
Semantic Versioning,
for now stay with X=0
.
Increment Z
by one if only bug fixes were made, and otherwise
increment Y
by one and reset Z
to zero.
In the directions below, replace X.Y.Z
with the release number you picked.
- In
shasta/.github/workflows/Build.yml
,
change BUILD_ID
to Shasta Release X.Y.Z
in all cmake
commands (5 instances at the time of last update of this documentation).
- Commit and push this change to trigger a new build on GitHub Actions.
Wait for that build to complete.
- Download the 7 artifacts. Unzip them and rename them to the following:
shasta-Linux-X.Y.Z
shasta-OldLinux-X.Y.Z
shasta-macOS-10.14-X.Y.Z
shasta-macOS-10.15-X.Y.Z
shasta-Ubuntu-16.04-X.Y.Z.tar
shasta-Ubuntu-18.04-X.Y.Z.tar
shasta-Ubuntu-20.04-X.Y.Z.tar
- Create release notes in markdown format.
This is
a web page that can be used to review
the release notes before posting on GitHub.
Just paste the markdown to the left pane.
- Create the release on GitHub and paste the release notes.
The release name should be just/simply
X.Y.Z
(no additional characters).
The release will not be visible to users until it gets published
two steps below.
- Upload the unzipped and renamed artifacts
to the new release as assets.
- Publish the release on GitHub.
- After the release has been published it should not be modified or deleted.
- In
shasta/.github/workflows/Build.yml
,
change BUILD_ID
to
Shasta unreleased test build newer than release X.Y.Z
in all cmake
commands for future GitHub Actions builds
(5 instances at the time of last update of this documentation).