To be discussed.
This guide is strongly based on the Prometheus release instructions.
We use Semantic Versioning.
We maintain a separate branch for each minor release, named release-<major>.<minor>
, e.g. release-1.1
, release-2.0
.
The usual flow is to merge new features and changes into the main branch and to merge bug fixes into the latest release branch. Bug fixes are then merged into main from the latest release branch. The main branch should always contain all commits from the latest release branch.
If a bug fix got accidentally merged into main, cherry-pick commits have to be created in the latest release branch, which then have to be merged back into main. Try to avoid that situation.
Maintaining the release branches for older minor releases happens on a best effort basis.
For a new major or minor release, work from the main
branch. For a patch release, work in the branch of the minor release you want to patch (e.g. release-0.3
if you're releasing v0.3.2
).
For new minor and major releases, create the release-<major>.<minor>
branch starting at the PR merge commit.
From now on, all work happens on the release-<major>.<minor>
branch.
Go to https://github.com/parca-dev/parca/releases/new and click on "Choose a tag" where you can type the new tag name.
Click on "Create new tag" in the dropdown and make sure main
is selected for a new major or minor release or the release-<major>.<minor>
branch for a patch release.
The title of the release is the tag itself.
You can generate the changelog and then add additional contents from previous a release (like social media links and more).
Alternatively, you can do the tagging on the commandline:
Tag the new release with a tag named v<major>.<minor>.<patch>
, e.g. v2.1.3
. Note the v
prefix.
git tag -s "v2.1.3" -m "v2.1.3"
git push origin "v2.1.3"
Signed tag with a GPG key is appreciated, but in case you can't add a GPG key to your Github account using the following procedure, you can replace the -s
flag by -a
flag of the git tag
command to only annotate the tag without signing.
Our CI pipeline will automatically push the container images to ghcr.io.
Go to https://github.com/parca-dev/parca/releases and check the created release.
For patch releases, submit a pull request to merge back the release branch into the main
branch.
Take a breath. You're done releasing.
The pipeline is configured to release Snap packages automatically to snapcraft.io.
The token for the store has a limited life. It can be regenerated like so (replace date placeholders!):
snapcraft export-login \
--snaps=parca \
--acls package_access,package_push,package_update,package_release \
--expires "YYYY-MM-DD" \
/tmp/parca_snap_token
The contents of /tmp/parca_snap_token
should then be added to a Github Secret called SNAPCRAFT_STORE_CREDENTIALS
.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。