Creating a new release
- Make sure there are no outstanding commits or
pull requests that should be in the new release.
- Do some testing.
- Run
CheckConfigurations.py
(from the shasta-install/bin
directory)
to check that all built-in configurations are functional.
- 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 (2 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 3 artifacts. Unzip them and rename them to the following:
shasta-Linux-X.Y.Z
shasta-Ubuntu-20.04-X.Y.Z.tar
shasta-docs-X.Y.Z.tar
- Make sure
shasta-Linux-X.Y.Z
is executable.
- Build Shasta for 64-bit ARM (
aarch64
). Github Actions currently does not support ARM. So the easiest way to do this is on a Graviton2 ec2 instance in AWS as follows:
git clone https://github.com/paoloshasta/shasta.git
sudo ./shasta/scripts/InstallPrerequisites-Ubuntu.sh
mkdir -p shastaBuild
cd shastaBuild
cmake ../shasta -DBUILD_ID="Shasta Release X.Y.Z for 64 bit ARM"
make install/strip -j
- Download the
aarch64
Shasta binary (using scp
) and
rename it to shasta-Linux-ARM-X.Y.Z
,
then make sure it is executable.
- 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.
- Include the minimum kernel version for each binary in the notes.
You can find this by running the `file` command (`file /path/to/shasta-*-X.Y.Z`)
- Create the release on GitHub and paste the release notes.
The release name should be just/simply
X.Y.Z
(no additional characters). Specify the tag to be created, also
X.Y.Z
without any additional characters.
The release will not be visible to users until it gets published
two steps below.
- Upload the unzipped and renamed artifacts (4) 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
(2 instances at the time of last update of this documentation).