Prepare for v3.8.0 release

hiddeco commented 1 year ago

I made a strong effort to push out a release before the anticipated arrival of a new family member (👶), but it appears I might not win this race at the moment. Given this, this issue primarily serves as documentation, enabling others to potentially step in and steer the course, or at the very least, a portion of it.

To-do

See open pull requests in milestone: https://github.com/getsops/sops/milestone/5

Plan

[x] Release v3.8.0-rc.1, mainly to ensure the new release process works as expected and we did not make any obvious mistakes while porting the previous release logic. I did take things for a test drive already, but better be safe than sorry.
- [x] Follow release procedure.
- [x] Once published, edit the release to include the release note draft.
- [x] Gather feedback for a period of time (1-2 weeks), via a GitHub Discussion.
[ ] Release v3.8.0
- [ ] Follow release procedure.
- [ ] Once published, edit the release to include the release note draft.

Release note draft

## Note from the maintainers

We're thrilled to introduce the release candidate of SOPS, now a [CNCF](https://cncf.io) Sandbox project under the stewardship of a new [group of maintainers](https://github.com/getsops/community/blob/main/MAINTAINERS.md).

This release involved significant effort in rewriting and enhancing key source implementations. Notably, we've modernized the code and updated all SDKs, including updating to AWS SDK v2. Some of these implementations had been neglected, lacking support for newer features. Now, they should be good for extended service.

Moreover, we've completely revamped the release process. Beyond delivering binaries and packages, it now provides enhanced assurance by publishing SBOMs (Software Bill of Materials), [SLSA3 provenance](https://slsa.dev/spec/v0.1/provenance), and a Cosign signed checksums file as GitHub release artifacts.

Additionally, the Darwin binary is now distributed as a ["fat binary"](https://en.wikipedia.org/wiki/Fat_binary#Apple), making it executable on both AMD64 and ARM64 machines.

The goal of this release candidate is primarily to validate our new release process and the quite impactful changes mentioned above. Take it for a spin and share your thoughts, your feedback is much appreciated!

### Important Information for SOPS SDK Users

With the project transitioning from the Mozilla Foundation to the CNCF, the Go module path has been updated to reflect this change in ownership. If you use `go.mozilla.org/sops/v3` as a library, going forward, import the Go Module using `github.com/getsops/sops/v3`. Apart from this small adjustment, the SDK's API remains fully backward compatible.

For a one-liner to quickly implement this change throughout your codebase, please refer to: https://github.com/getsops/sops/issues/1246#issuecomment-1625526429

felixfontein commented 1 year ago

Is the naming change for the RPM packages intentionally? For 3.7.3, they were named

sops-3.7.3-1.aarch64.rpm
sops-3.7.3-1.x86_64.rpm

(note the -1 after the version), while for 3.8.0-rc.1 they are named

sops-3.8.0.rc.1.aarch64.rpm
sops-3.8.0.rc.1.x86_64.rpm

(without the -1).

hiddeco commented 1 year ago

I could not trick GoReleaser in reproducing the exact format, which has been noted in #1250. They are now using the "convential filename" formats, instead of the hardcoded -1 default previously: https://github.com/getsops/sops/blob/v3.7.3/.github/workflows/release.yml#L64-L65.

hiddeco commented 1 year ago

As the baby decided it was time to see the world quite soon after I pushed the release. I propose we set the final date for gathering feedback on the day I return from my paternity leave (September 11), with a release target date between September 11 - 15.

LucidOne commented 1 year ago

First, :tada:

Some minor nits... Personally, I'd prefer v3.8.0_rc1 for a release candidate version AFAICT, the provenance file should be versioned. provenance.intoto.jsonl -> https://github.com/getsops/sops/releases/download/v3.8.0_rc1/sops-v3.8.0_rc1.intoto.jsonl

The release tarball has inconsistent versions naming. v3.8.0-rc.1 vs 3.8.0-rc.1

$ wget https://github.com/getsops/sops/archive/refs/tags/v3.8.0-rc.1.tar.gz
Connecting to github.com (140.82.121.4:443)
Connecting to codeload.github.com (140.82.121.9:443)
saving to 'v3.8.0-rc.1.tar.gz'
v3.8.0-rc.1.tar.gz   100% |*********************************************************|  221k  0:00:00 ETA
'v3.8.0-rc.1.tar.gz' saved
$ tar -ztf v3.8.0-rc.1.tar.gz | head -1
sops-3.8.0-rc.1/

felixfontein commented 1 year ago

Regarding the version: 3.8.0-rc.1 conforms to semantic versioning, while 3.8.0_rc1 does not. The v is a common prefix for version tags used in git / on GitHub.

schuerg commented 1 year ago

Regarding the version: 3.8.0-rc.1 conforms to semantic versioning, while 3.8.0_rc1 does not. The v is a common prefix for version tags used in git / on GitHub.

In my experience, it is better to use exactly the same notation for version identifiers in software, git tags, container image tags, filenames and other places e.g. GitHub releases. It avoids confusion, makes scripting easier, and simplifies things. By this I mean omitting the v prefix in both git tags and GitHub release names. Using an established version notation like semantic versioning, which makes it clear that preversions are written as suffixes like -rc.1, also makes sense to me.

Filenames could then be defined as sops-{VERSION}-{arch}-{os}.{fileformat}

hiddeco commented 1 year ago

We are quite literally continuing the tagging strategy as used for the last range of previous releases of SOPS, before we took over stewardship.

In addition, the release artifact names equal to the names of previous releases, ensuring backwards compatibility with any automation scripts people may have written in the past. While the source archive is generated by GitHub, and any naming there is beyond our control.

Given this, I do not think anything mentioned here is really up for discussion.

getsops / sops