Release process v2

[guergabo]

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

• [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?
• [x] Documentation, generated sdk comments embedded. Compensations (Charge & Refund). Use cases: AI, Payments...

Vipul

• [x] Entry point. Brew install , apt. (linux), Propose strategy.
• [x] Come up with a strategy to align with the SDK releases.

Additional context

For context this is an example of how Istio does it: https://github.com/istio/release-builder.

• Let's take into account that we want to be able to release candidates (rc-1, rc-2, rc-2), before the final actual release.

[dtornow]

Please update Playbook, Release Process with documentation of the release process including the GitHub branching model

[dfarr]

Closing this issue, we can create follow up issues later for missing bullet point items