Currently we are just releasing raw binaries. We should make our release/distribution strategy more mature with the following:
Release & Entry Point (Packaging & distribution of Resonate)
Gabe
[x] Our release process should publish our docker images. Look into using sigstore to cryptographically sign for provenance.
[x] Our binary release artifact should be compressed per target as a *.tar.gz. Our artifacts should include a SHA256 checksum file that can be used by users to verify the integrity of the binary release archive (*.tar.gz.sha256).
[ ] Before v1.0 our compressed folder should contain the yaml manifest (deployment) files users may use for deployment onto kubernetes clusters.
[ ] Add window binary support. (winget)
Together
[x] Our release process should support the build, publish, and branching steps. As much of it should be as automated as possible. Once we hit the v1.0 milestone, we must use a release branching strategy to support hot fixes for at least 2 previous minor releases. Release candidate selection vs final release?
Describe the problem you are facing
Currently we are just releasing raw binaries. We should make our release/distribution strategy more mature with the following:
Release & Entry Point (Packaging & distribution of Resonate)
Gabe
*.tar.gz
. Our artifacts should include a SHA256 checksum file that can be used by users to verify the integrity of the binary release archive (*.tar.gz.sha256
).Together
build
,publish
, andbranching
steps. As much of it should be as automated as possible. Once we hit the v1.0 milestone, we must use a release branching strategy to support hot fixes for at least 2 previous minor releases. Release candidate selection vs final release?Vipul
Additional context
For context this is an example of how Istio does it: https://github.com/istio/release-builder.