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 6 artifacts. Unzip them and rename them to the following:
shasta-Linux-X.Y.Z
shasta-OldLinux-X.Y.Z
shasta-macOS-X.Y.Z
shasta-Ubuntu-20.04-X.Y.Z.tar
shasta-Ubuntu-18.04-X.Y.Z.tar
shasta-Ubuntu-16.04-X.Y.Z.tar
- Build Shasta for 64-bit ARM (
aarch64
). Github Actions currently don't support aarch64
containers. So the easiest way to do this is on a Graviton2 ec2 instance in AWS. On an aarch64
instance running Ubuntu 20.04 LTS, do the following:
git clone git@github.com:chanzuckerberg/shasta.git
sudo ./shasta/scripts/InstallPrerequisites-Ubuntu.sh
mkdir -p shasta-build
cd shasta-build
cmake ../shasta -DBUILD_ID="Shasta Release X.Y.Z for 64 bit ARM"
make install -j
- Download the
aarch64
Shasta binary (using scp
) and rename it to shasta-Linux-ARM-X.Y.Z
. This is the seventh artifact for the release.
- 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).
The release will not be visible to users until it gets published
two steps below.
- Upload the unzipped and renamed artifacts (seven) 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).