You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As always, thanks to contributors old and new for helping improve Spin on a daily basis! 🎉
12
+
13
+
### Verifying the Release Signature
14
+
15
+
After downloading the <version> release of Spin, either via the artifact attached to this release corresponding to your OS/architecture combination or via the [installation method of your choice](https://developer.fermyon.com/spin/install#installing-spin), you are ready to verify the release signature.
16
+
17
+
First, install [cosign](https://docs.sigstore.dev/cosign/installation/). This is the tool we'll use to perform signature verification. Then run the following command:
To cut a major / minor release of Spin, you will need to do the following:
11
+
This is a guide for releasing a new version of Spin.
12
12
13
-
1. Create a release branch, e.g. `v2.0`. With our branch protection rules this is easiest from the Github UI with the [New Branch button here](https://github.com/fermyon/spin/branches).
13
+
The main steps are as follows:
14
14
15
-
1. Switch to the release branch locally and update versions (e.g. `2.0.0-pre0` could be `2.0.0`).
16
-
- Bump the version in Spin's `Cargo.toml`
17
-
- Run `make build update-cargo-locks` so that `Cargo.lock` and example/test `Cargo.lock` files are updated
18
-
19
-
PR these changes to the release branch ensuring that pull request has a base corresponding to the release branch (e.g. `v2.0`).
15
+
-[Designate a release commit](#designate-release-commit)
16
+
-[Switch to release branch and bump versions](#switch-to-release-branch-and-bump-versions)
1. Create a new tag with a `v` and then the version number, e.g. `v2.0.0`. Then, push the tag to the `fermyon/spin` origin repo.
22
-
23
-
As an example, via the `git` CLI:
21
+
## Designate release commit
24
22
25
-
```
26
-
# Switch to the release branch
27
-
git checkout v2.0
28
-
git pull
23
+
When ready to release the next version of Spin, first locate the commit that will serve as its basis. In other words, the last functional commit to be included besides the version bump commit that will be created below.
29
24
30
-
# Create a GPG-signed and annotated tag
31
-
git tag -s -m "Spin v2.0.0" v2.0.0
25
+
Ensure that CI/CD is green for this commit, specifically the [Build](https://github.com/fermyon/spin/actions/workflows/build.yml) workflow and, if applicable, the [Release](https://github.com/fermyon/spin/actions/workflows/release.yml) workflow.
32
26
33
-
# Push the tag to the remote corresponding to fermyon/spin (here 'origin')
34
-
git push origin v2.0.0
35
-
```
27
+
## Switch to release branch and bump versions
36
28
37
-
1. Switch back to `main` and update the `Cargo.toml` version again, this time to e.g. `2.1.0-pre0` if `2.1.0` is the next anticipated release.
38
-
- Run `make build update-cargo-locks` so that `Cargo.lock` and example/test `Cargo.lock` files are updated
39
-
- PR this to `main`
40
-
- See [sips/011-component-versioning.md](sips/011-component-versioning.md)
41
-
for details
29
+
1. If this is a major/minor release (e.g. `v2.0.0`) or a first release candidate (e.g. `v2.0.0-rc.1`), create the release branch from the designated commit. The branch name should include the major and minor version but no patch version, e.g. `v2.0`. With our branch protection rules this is easiest from the Github UI with the [New Branch button here](https://github.com/fermyon/spin/branches).
42
30
43
-
Follow the [wrapping up](#wrapping-up) section to finish off the release process.
31
+
1. Otherwise, if this is a patch release or subsequent release candidate, a release branch will already exist.
44
32
45
-
## Patch release
33
+
> **Note**: For a patch release, first backport the commits you wish to include to the release branch you're creating the patch release for. Use the [backport script](https://github.com/fermyon/spin/blob/main/.github/gh-backport.sh) to do so, e.g.
46
34
47
-
To cut a patch release of Spin, you will need to do the following:
1. Backport the commits you wish to include to the release branch you're creating the patch release for. **NOTE** Use the [backport script](https://github.com/fermyon/spin/blob/main/.github/gh-backport.sh) to do so.
1. Switch to the release branch locally and update versions (e.g. `2.0.0` could be `2.0.1`).
45
+
1. Update versions
46
+
- For example, `2.0.0-pre0` could be `2.0.0` for a major release, `2.0.1` for a patch and `2.0.0-rc.1` for a release candidate
56
47
- Bump the version in Spin's `Cargo.toml`
57
48
- Run `make build update-cargo-locks` so that `Cargo.lock` and example/test `Cargo.lock` files are updated
58
49
59
-
PR these changes to the release branch ensuring that pull request has a base corresponding to the release branch (e.g. `v2.0`).
50
+
1. PR these changes to the release branch, ensuring that the pull request has a base corresponding to the release branch (e.g. `v2.0`).
51
+
52
+
## Create the git tag
53
+
54
+
> Note: these steps require write permissions to the Spin repo
60
55
61
-
1. Create a new tag with a `v` and then the version number, e.g. `v2.0.1`. Then, push the tag to the `fermyon/spin` origin repo.
56
+
1. Once the version bump PR is approved and merged, confirm that CI is green for that merge commit.
57
+
58
+
1. Create a new tag from the merge commit. The tag should begin with a `v`, followed by the version number, e.g. `v2.0.0`. Then, push the tag to the `fermyon/spin` origin repo.
# Push the tag to the remote corresponding to fermyon/spin (here 'origin')
74
-
git push origin v2.0.1
71
+
git push origin v2.0.0
75
72
```
76
73
77
-
Follow the [wrapping up](#wrapping-up) section to finish off the release process.
74
+
This will trigger the [Release](https://github.com/fermyon/spin/actions/workflows/release.yml) workflow which produces and signs release artifacts and uploads them to a GitHub release.
78
75
79
-
## Release Candidate
76
+
1. If this is a major/minor release, switch back to `main` and update the `Cargo.toml` version again, this time to e.g. `2.1.0-pre0` if `2.1.0` is the next anticipated release. _(Patch and release candidates can skip this step.)_
77
+
- Run `make build update-cargo-locks` so that `Cargo.lock` and example/test `Cargo.lock` files are updated
78
+
- PR this to `main`
80
79
81
-
To create a release candidate for a major/minor version of Spin, you will need to do the following:
80
+
## Write release notes
82
81
83
-
1. Create the release branch if not already created. With our branch protection rules this is easiest from the Github UI with the [New Branch button here](https://github.com/fermyon/spin/branches).
84
-
Otherwise, switch to the branch locally.
82
+
The [release notes template](./release-notes-template.md) can be used as a guide and starting point.
85
83
86
-
1. Update the Spin version with `-rc.N` where `N` is the release candidate number (e.g. `2.0.0-pre0` could be `2.0.0-rc.1`).
87
-
- Bump the version in Spin's `Cargo.toml`
88
-
- Run `make build update-cargo-locks` so that `Cargo.lock` and example/test `Cargo.lock` files are updated
84
+
A good way to familiarize oneself with the features, fixes and other changes in a release is to look at the comparison URL in GitHub,
85
+
e.g. `https://github.com/fermyon/spin/compare/<previous tag>...main`. Often commit messages will indicate whether it is a feature, fix,
86
+
docs, chore or other PR. However, you may also need to click into the closed pull request linked to a commit to gain more context.
89
87
90
-
PR these changes to the release branch ensuring that pull request has a base corresponding to the release branch (e.g. `v2.0`).
88
+
Once the GitHub release is created, edit the release with these notes.
91
89
92
-
1. Create a new tag with a `v` and then the version used above, e.g. `v2.0.0-rc.1`. Then, push the tag to the `fermyon/spin` origin repo.
90
+
> Note: the GitHub release created by the automation pipeline will come pre-populated with title and changelog. Be sure that the changelog uses the correct previous tag/version. If it does not, edit the release to update the previous tag/version and regenerate the changelog. This auto-generated changelog can be added at the end of the release notes.
93
91
94
-
As an example, via the `git` CLI:
92
+
## Notify downstream projects
95
93
96
-
```
97
-
# Switch to the release branch
98
-
git checkout v2.0
99
-
git pull
94
+
There are a handful of projects that use Spin and would appreciate notification of a new release.
100
95
101
-
# Create a GPG-signed and annotated tag
102
-
git tag -s -m "Spin v2.0.0-rc.1" v2.0.0-rc.1
96
+
### Spin Docs
103
97
104
-
# Push the tag to the remote corresponding to fermyon/spin (here 'origin')
105
-
git push origin v2.0.0-rc.1
106
-
```
98
+
- Documentation for Spin exists in the [fermyon/developer](https://github.com/fermyon/developer) repository. Based on the changes remarked upon in the release notes, check to see if any documentation may be missing. If so, either file issues in the repo, create the documentation PR(s) or reach out in the [Spin channel on Fermyon's Discord](https://discord.com/channels/926888690310053918/950022897160839248).
99
+
100
+
At a minimum, the CLI reference will need to be added per the new Spin release. Again, this can be tracked as an issue in the repo or, if creating the PR directly, check out the [current automation](https://github.com/fermyon/developer/tree/main/toolkit) for creating the updated markdown.
101
+
102
+
### SpinKube
107
103
108
-
Follow the [wrapping up](#wrapping-up) section to finish off the release process.
104
+
- The [Containerd Shim Spin](https://github.com/spinkube/containerd-shim-spin) project often organizes its next release around a new version of Spin.
109
105
110
-
## Wrapping up
111
-
1. Go to the GitHub [tags page](https://github.com/fermyon/spin/releases),
112
-
edit the release and add the release notes. (This step is optional if a release candidate.)
106
+
- Consider announcing the new release in the [SpinKube CNCF Slack channel](https://cloud-native.slack.com/archives/C06PC7JA1EE).
113
107
114
-
1. Be sure to include instructions for
115
-
[verifying the signed Spin binary](./sips/012-signing-spin-releases.md). The
116
-
`--certificate-identity` value should match this release, e.g.
- If a contributor to the project, you might also create a PR bumping Spin crate versions. Often this requires bumping the wasmtime version(s) to suit, as well as orchestrating releases of associated projects such as [spin-trigger-command](https://github.com/fermyon/spin-trigger-command) and [spin-trigger-sqs](https://github.com/fermyon/spin-trigger-sqs), with their Spin crate versions bumped to the same.
118
109
119
-
1. Unless this is a release candidate, review and merge the bot-created Pull Request
120
-
in the [fermyon/homebrew-tap repository](https://github.com/fermyon/homebrew-tap/).
110
+
### Fermyon Cloud
121
111
122
-
The release is now complete!
112
+
- The [Fermyon Cloud plugin](https://github.com/fermyon/cloud-plugin) project commonly updates its Spin version to acquire new features and fixes.
0 commit comments