Skip to content

Commit b9c736f

Browse files
alexcrichtonalexcrichton
authored
Merge pull request #42 from alexcrichton/wasmtime-lts
Add an LTS channel of release for Wasmtime
2 parents 0300c5f + e51fb45 commit b9c736f

File tree

1 file changed

+255
-0
lines changed

1 file changed

+255
-0
lines changed

‎accepted/wasmtime-lts.md

Lines changed: 255 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,255 @@
1+
# Summary
2+
3+
[summary]: #summary
4+
5+
Add a Long Term Support (LTS) channel of releases for Wasmtime. LTS releases for
6+
Wasmtime will be every 12 versions at versions starting at 24.0.0. LTS releases
7+
are supported for 24 releases (2 years) to ensure that there is always at least
8+
two LTSes at any one point in time.
9+
10+
# Motivation
11+
[motivation]: #motivation
12+
13+
Currently Wasmtime's [release process][process] is such that a new release is
14+
made once a month. Security patches are guaranteed for the current and previous
15+
release of Wasmtime, meaning that a release of Wasmtime receives guaranteed
16+
security updates for two months. This release/security cadence was designed a
17+
few years back when Wasmtime was first release and it was known at the time that
18+
it was pretty aggressive in terms of support and dropping older versions and
19+
that we might want to revisit it in the future. Essentially, now seems as
20+
reasonable a time as any to reconsider this.
21+
22+
As Wasmtime has matured it's clear that not all possible users of Wasmtime will
23+
find the current release cadence reasonable. Embeddings might not have the
24+
energy/resources to track the once-a-month release of Wasmtime but at the same
25+
time still desire security updates. Currently there's not much that can be done
26+
other than hope for the best when using Wasmtime.
27+
28+
Supporting an LTS channel for Wasmtime, however, is not free. The original
29+
rationale for not supporting it is that it costs engineering resources to
30+
maintain and additionally no current users needed that. While the latter part of
31+
this equation is being reconsidered it's worth going over the costs of an LTS
32+
with as well. Some more discussion can be found in [#10161][issue], but a
33+
summary is:
34+
35+
* Security updates are required for an LTS. For 2023 and 2024 Wasmtime had 8
36+
CVEs and all were generally easy to backport. Overall the prediction is that
37+
we won't be spending all our time trying to figure out how to backport CVEs to
38+
older branches of Wasmtime.
39+
40+
* Bug fixes are likely going to be optional for an LTS. If an LTS release
41+
doesn't guarantee we backport all bug fixes then we don't have to always do
42+
the work of backporting and identifying bug fixes. It's assumed, though, that
43+
bug fix backports will always be accepted regardless so long as someone's
44+
willing to do the work.
45+
46+
* Feature backports are currently planned to not be supported at all, even if
47+
someone's willing to do the work to backport it. In addition to being
48+
significantly more difficult to review large additions to old snapshots of the
49+
codebase the rationale is that we want to reduce the risk of bugs being
50+
accidentally introduced into an LTS.
51+
52+
* Long release windows have a risk of rushing all pending features in just
53+
before a new release is made, and this is a theoretical concern about
54+
attempting to rush a feature in before an LTS branch is cut. This concern is
55+
projected to be mitigated by the normal release schedule, however, where if
56+
new features are necessary for an embedding it can ride that release train
57+
(updating each month) until the next LTS and then ride the LTS.
58+
59+
* Release automation atrophying is a chief concern that still needs mitigation.
60+
The current thinking is to somehow do a "dry run" periodically and ensure that
61+
the automation is up-to-date to remind maintainers to take a look and backport
62+
any CI tweaks as necessary. This is mostly mitigated by pinning rustc versions
63+
but breakage inevitably still occurs.
64+
65+
The general summary though is that an LTS has always been well-motivated and
66+
now seems about right to implement it. The reasons to not initially do an LTS
67+
are not as applicable nowadays, hence this RFC.
68+
69+
One final question that's reasonable to address here is "why now?" For example
70+
why propose an LTS release now when there isn't necessarily a cohort of dozens
71+
of embedders all banging on the door asking for it. The main rationale is that
72+
if we have dozens of such embedders it's probably too late to start an LTS at
73+
that time and it should have been done many moons earlier. Effectively the goal
74+
of this RFC is to signal to the community that the project is ready for LTS
75+
channels and users which may have been hesitant to Wasmtime might be convinced
76+
by this change. It's not expected we'll see anything like a massive influx of
77+
users, but instead this is generally what's expected of a well-established open
78+
source project with critical security requirements.
79+
80+
[process]: https://docs.wasmtime.dev/stability-release.html
81+
[issue]: https://github.com/bytecodealliance/wasmtime/issues/10161
82+
83+
# Proposal
84+
[proposal]: #proposal
85+
86+
Wasmtime will add a new type of release to its release process, a Long Term
87+
Support (LTS) release. LTS releases will happen every 12th release of Wasmtime
88+
(once a year), starting with 24.0.0 (retroactively classified as LTS). Each LTS
89+
will be supported for 24 versions, or 24 months/2 years. Overlapping LTS
90+
windows enables users of the LTS release to upgrade on their own time from one
91+
LTS to another. At this time though it's expected that LTS users will likely
92+
upgrade from one LTS to another, for example a user of 36.0.0 could upgrade to
93+
48.0.0 as late as when 52.0.0 is released.
94+
95+
LTS releases for Wasmtime will have the following properties:
96+
97+
* Security fixes for CVEs are guaranteed to be backported to LTS releases.
98+
* Bug fixes are not guaranteed to be backported, but anyone can request a
99+
backport or send a PR which will be reviewed to backport a bug fix. Bug fixes
100+
are required to land on `main` first, however.
101+
* New features are not supported on LTS releases, even if someone sends a PR.
102+
* Backports are required to not increase the minimum-supported-Rust-version
103+
(MSRV) from when the LTS branch was created. This means that the same version
104+
of Rust can be used to compile an LTS branch for its entire lifecycle.
105+
* Platform compatibility of LTS branches may change over time as build
106+
containers/distributions reach EOL. For example if a GitHub Actions runner is
107+
discontinued during the lifecycle of an LTS and it's in use for that LTS's CI,
108+
then we'll be forced to update the image which may increase the platform
109+
compatibility. We'll always strive to update as minimally as possible if an
110+
update is required.
111+
112+
LTS releases will be automated the same way all releases are managed for
113+
Wasmtime today. A dedicated `release-N.0.0` branch is created and then further
114+
releases are made from that branch. Subsequent releases of LTSes for CVEs or bug
115+
fixes will be versioned by incrementing the patch version of semver, for example
116+
36.0.1. A patch release is made via [today's release process][patches]
117+
118+
Wasmtime will continue to guarantee security fixes and support bug fix backports
119+
for the current release of Wasmtime and the previous release of Wasmtime as
120+
well. For example if the current release is 47.0.0 then a CVE will trigger a
121+
release of 24.0.1 (lts), 36.0.1 (lts), 46.0.1 (n-1), and 47.0.1 (n).
122+
123+
To see this proposal visually this is a diagram of when a release starts (the
124+
start of its box) to the final date such a release receives security fixes (the
125+
end of its box)
126+
127+
```mermaid
128+
gantt
129+
title LTS Schedule
130+
dateFormat YYYY-MM-DD
131+
section lts1
132+
24.0.0 :a1, 2024-08-20, 720d
133+
30.0.0 :a1, 2025-02-20, 60d
134+
31.0.0 :a2, 2025-03-20, 60d
135+
32.0.0 :a2, 2025-04-20, 60d
136+
33.0.0 :a2, 2025-05-20, 60d
137+
34.0.0 :a2, 2025-06-20, 60d
138+
35.0.0 :a2, 2025-07-20, 60d
139+
section lts2
140+
36.0.0 :a2, 2025-08-20, 720d
141+
37.0.0 :a2, 2025-09-20, 60d
142+
38.0.0 :a2, 2025-10-20, 60d
143+
39.0.0 :a2, 2025-11-20, 60d
144+
40.0.0 :a1, 2025-12-20, 60d
145+
41.0.0 :a2, 2026-01-20, 60d
146+
42.0.0 :a2, 2026-02-20, 60d
147+
43.0.0 :a2, 2026-03-20, 60d
148+
44.0.0 :a2, 2026-04-20, 60d
149+
45.0.0 :a2, 2026-05-20, 60d
150+
46.0.0 :a2, 2026-06-20, 60d
151+
47.0.0 :a2, 2026-07-20, 60d
152+
section lts3
153+
48.0.0 :a2, 2026-08-20, 720d
154+
49.0.0 :a2, 2026-09-20, 60d
155+
50.0.0 :a1, 2026-10-20, 60d
156+
```
157+
158+
This means that once two LTS channels are in play there will 4 releases of
159+
Wasmtime which receive security fixes at any one point in time.
160+
161+
[patches]: https://docs.wasmtime.dev/contributing-release-process.html#releasing-a-patch-version
162+
163+
## Schedule Constraints
164+
165+
There are a number of possibilities around how exactly to set the parameters for
166+
LTS. Here it's chosen that an LTS happens once-a-year at versions divisible
167+
by 12. Versions are then supported for 24 months. This cadence is specifically
168+
chosen to enable users to update Wasmtime once per year and always be on a
169+
supported LTS version. This is seen as a good rule of thumb we can give
170+
embedders where they get to choose when during the year to upgrade so long as
171+
one upgrade happens per year.
172+
173+
## LTS and CI
174+
175+
While a relatively boring topic for most the integration of Continuous
176+
Integration (CI) into Wasmtime's release process means that this can't go
177+
entirely un-mentioned from this RFC. While Wasmtime generally pins versions of
178+
dependencies (e.g. rustc) in CI it inevitably has breakage over time in
179+
situations such as:
180+
181+
* GitHub Actions might retire an image (e.g. `ubuntu-20.04`) completely.
182+
* We might discover that our CI accidentally depends on a live service that goes
183+
offline.
184+
* We might discover bugs in our CI configuration which need fixing.
185+
186+
In all of these scenarios we don't want to discover this when a CVE is being
187+
released -- there's nothing worse than trying to debug 10-month-old CI
188+
configuration and puzzling over what's going wrong. To address this situation
189+
this RFC proposes new automation to ensure that release branches are kept
190+
up-to-date and green at all times, always ready to make a release.
191+
192+
The specific changes that will be made to Wasmtime's CI is:
193+
194+
* A new [`workflow_dispatch` trigger][wdtrigger] will get added to the
195+
`main.yml` CI.
196+
* A new `schedule` cron job-based action will be added to the `main` branch of
197+
Wasmtime (the `schedule` trigger [only works on the main branch][ghamain]).
198+
This new job will run once-a-week.
199+
* A script will be added to the repository to calculate the current set of LTS
200+
branches.
201+
* This script will execute [`gh workflow run`] for each release branch,
202+
executing the full `main.yml` CI for the release branch.
203+
* CI will be updated to skip auto-publishing/tagging/etc when the trigger is
204+
`workflow_dispatch`.
205+
* CI will be updated to file an issue on the repository using
206+
[actions/github-script] if the dispatched run fails (as otherwise
207+
notifications won't get sent out).
208+
209+
This should ensure that CI is at most 1 week old and only needs 1 week worth of
210+
fixes which should always be pretty fresh in our minds. Otherwise this ensures
211+
that our CI continues operating normally as it did at the time of the LTS branch
212+
creation.
213+
214+
[ghamain]: https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#schedule
215+
[wdtrigger]: https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_dispatch
216+
[`gh workflow run`]: https://cli.github.com/manual/gh_workflow_run
217+
[actions/github-script]: https://github.com/actions/github-script
218+
219+
## LTS and Features
220+
221+
As-specified LTS branches will receive no new feature development, even if
222+
someone were to send a PR and request it be merged. Instead such a PR would
223+
be closed saying "we don't support this." As mentioned in the [motivation]
224+
section this can raise the risk of attempting to rush features in before an LTS
225+
branch is cut to have them supported during that LTS cycle.
226+
227+
Mitigations for this release pressure are to (a) continue to support a
228+
once-a-month release schedule and (b) communicate that users can still fork the
229+
repository and backport the feature themselves. For (a) there are no changes to
230+
Wasmtime's normal release process in this RFC so there's still a single release
231+
every month, the only change is how long some releases are supported (aka LTS
232+
releases). For (b) some production users are already doing this today and it's
233+
expected that if both LTS and a feature which didn't make it are important that
234+
it's reasonable to ask the user to maintain their own fork. Such a fork should
235+
still be able to benefit from security backports made to the official LTS
236+
branch.
237+
238+
# Rationale and alternatives
239+
[rationale-and-alternatives]: #rationale-and-alternatives
240+
241+
* The major alternative to this design is to not support an LTS at all and
242+
continue on Wasmtime's current path of only guaranteeing the
243+
current-and-previous releases get security fixes. It's seen though that this
244+
is likely excluding too many potential users of Wasmtime, hence this RFC.
245+
246+
* Another alternative is to support only one LTS at a time. The problem with
247+
this is that users of an LTS should have a period of time to upgrade from one
248+
to the other where both LTS releases are supported. Otherwise if an upgrade
249+
takes an unexpectedly long time then if a security issue happens it won't get
250+
backported to the old LTS release.
251+
252+
# Open questions
253+
[open-questions]: #open-questions
254+
255+
None at this time.

0 commit comments

Comments
 (0)