-
Notifications
You must be signed in to change notification settings - Fork 119
Release process
Releases of dattobd are made as needed.
dattobd uses a <major>.<minor>.<patch> scheme for versions (e.g., 0.10.9).
The version is modifed when preparing the release, such that the commit that changes the version is the commit that gets tagged and released.
Tags should be formatted as v<major>.<minor>.<patch> (e.g., v0.10.9).
Tags should be signed with a GPG signing key. Ensure you are using GPG 2.1 or newer. As a reference, read the Linux developer PGP guide.
To push tags you'll also need a valid Github API token with push access: https://github.com/settings/tokens
A changelog is prepared at the time of the release.
- Review the commits since the previous tag for release information
- Review the associated issues and pull requests for addition information
As a reference, these were the steps for creating the 0.10.9 release.
# Write a changelog based on commits
git checkout master
git pull upstream master
git log v0.10.8...HEAD
# Modify version, add changelog
vim dist/dattobd.spec
# Modify version
vim src/dattobd.h
git add src/dattobd.h dist/dattobd.spec
git commit -m "Version 0.10.9"
git tag -u $GPGKEYID -m "Version 0.10.9" v0.10.9
# Verify the correct key was used
git tag -v v0.10.9
git push upstream master
git push upstream v0.10.9
firefox https://github.com/datto/dattobd/releases/newOn the new release draft page:
- Specify the tag as the release tag name:
v0.10.9 - Specify the version as the release title:
0.10.9 - Add the changelog and any relevant notes to the description
- Click "Publish release"
The release is now available on GitHub.
The packages for distros must be built and deployed on https://cpkg.datto.com. This is handled by the DevOps team using internal infrastructure. Create an internal ticket for DevOps to publish the new release.
Finally, when the new release is published, send a message to the internal release mailing list to inform stakeholders.