rfcs / PR #42 Add an LTS channel of release for Wasmtime · rfc-notifications

Stream: rfc-notifications

Topic: rfcs / PR #42 Add an LTS channel of release for Wasmtime

RFC notifications bot (Feb 10 2025 at 19:58):

alexcrichton opened PR #42 from alexcrichton:wasmtime-lts to bytecodealliance:main:

This is borne out of discussion on bytecodealliance/wasmtime#10074 and bytecodealliance/wasmtime#10161 and proposes adding an LTS channel for Wasmtime. The general tl;dr; is:

Wasmtime LTS releases will be every 10th release, or 10 months apart.

LTS releases are supported for 20 months.

LTS releases are guaranteed to receive security fixes, and may optionally receive bug fixes. Feature backports are not supported, even if they're provided.

RFC notifications bot (Feb 10 2025 at 20:00):

alexcrichton edited PR #42:

This is borne out of discussion on bytecodealliance/wasmtime#10074 and bytecodealliance/wasmtime#10161 and proposes adding an LTS channel for Wasmtime. The general tl;dr; is:

Wasmtime LTS releases will be every 10th release, or 10 months apart.

LTS releases are supported for 20 months.

LTS releases are guaranteed to receive security fixes, and may optionally receive bug fixes. Feature backports are not supported, even if they're provided.

Rendered

RFC notifications bot (Feb 10 2025 at 20:04):

alexcrichton updated PR #42.

RFC notifications bot (Feb 10 2025 at 20:06):

alexcrichton updated PR #42.

RFC notifications bot (Feb 10 2025 at 20:10):

alexcrichton commented on PR #42:

Some more bits from https://github.com/bytecodealliance/wasmtime/issues/10161 I want to fill in:

Add some wording about how we still want to avoid the "rush in the features before LTS" problem of feature-based releases

Add some wording about how we still intend to balance such feature pressure with regular releases

Add words about how users can always fork an LTS branch as a "stable base" and add their own features while still getting security backports from upstream

Probably add a bit more wording about how this is intended to signal stability/maturity and how we're trying to proactively do this rather than waiting for a cacophony of users requesting an LTS release

RFC notifications bot (Feb 26 2025 at 21:03):

fitzgen submitted PR review:

Thanks for writing this up! I am in favor.

RFC notifications bot (Feb 26 2025 at 21:03):

fitzgen created PR review comment:

How about a weekly cron CI job for all release-* branches that checks if this is an LTS release and then does a full CI run if so? I'll throw out sunday mornings as a good time to schedule this.

Ideally this would also file an issue on failure as well...

RFC notifications bot (Feb 26 2025 at 21:03):

fitzgen created PR review comment:

I would be in favor of starting with 15 months of support (2-month overlap seems perhaps too short; half of time till the next LTS seems nice and round) and then re-evaluating whether to extend that to 20 after the first LTS goes out of support, as you suggest. (FWIW: At that time, if we extend to 20, I don't think we should need to go through the whole RFC process again.)

RFC notifications bot (Feb 26 2025 at 23:08):

alexcrichton updated PR #42.

RFC notifications bot (Feb 26 2025 at 23:09):

alexcrichton submitted PR review.

RFC notifications bot (Feb 26 2025 at 23:09):

alexcrichton created PR review comment:

Makes sense yeah, I thought through some of the particulars here and I wrote up some more detailed discussion of what I think the CI will look like and why I think it's reasonable.

RFC notifications bot (Feb 26 2025 at 23:09):

alexcrichton submitted PR review.

RFC notifications bot (Feb 26 2025 at 23:09):

alexcrichton created PR review comment:

Sounds good to me, updated :+1:

RFC notifications bot (Mar 13 2025 at 17:00):

fitzgen commented on PR #42:

One thing I thought of during the discussion of this RFC in today's Wasmtime meeting: it would be good to make a list of the docs that should be updated to describe/link to/mention the LTS releases.

Off the top of my head:

[ ] probably makes sense to have a whole new page in the guide, maybe nested under Stability > Release Process

[ ] the Security section of the guide should be updated as well, not sure where exactly, but at minimum the vulnerability runbook should have the relevant step updated

[ ] probably makes sense to mention and link to from somewhere in the top-level README.md (and wasmtime.dev, whose contents probably need to be re-synced with the top-level README.md)

[ ] does it make sense to update the wasmtime crate's top-level rust docs to include a link to this?

RFC notifications bot (Mar 13 2025 at 17:17):

cfallin commented on PR #42:

After the discussion on this topic today in the Wasmtime biweekly, I thought a little more about the timeline configuration. To recap, in the meeting we discussed a potential requirement that it should be possible for a user to stay up-to-date with LTS releases by upgrading once a year at the same point in the year.

As we noted in the meeting, the current 10-month cadence with 15-month support doesn't meet this requirement: one must upgrade at a point in time when two LTS releases are currently supported (or else this implies one was using an unsupported release); there is a 5-month window every 10 months when this is the case; that 5-month window shifts throughout the calendar over the years.

We discussed a 20-month support window instead, so there are always two LTS releases that are supported. This does mean that one could upgrade at any point during the year. However, it has another issue: one could fall behind if one only upgrades once a year. To see this, observe that with only two LTS releases supported at a time, one must keep up to date by always upgrading n -> n + 1; i.e., never skipping a version (because n and n + 2 are never under support simultaneously). This means that one must upgrade once for every LTS release, and LTS releases happen every 10 months.

To be a little more precise: what will happen is that every 60 months (5 years, the LCM of 10 and 12 months), one will be on version n when the upgrade point in the year comes at the same time as the release of n + 2, and n will go out of support before one can upgrade off of it.

I think there are two ways out if we want to support this requirement:

Adjust to base-12: LTS versions released every 12 months, supported for 24 months. This would definitely allow a fixed-point-in-year upgrade cycle to keep up with a timeframe for the upgrade up to one year, depending on the offset between the release point and one's upgrade schedule.

Adjust to a 3x multiplier: on the 10-month base, this would mean 30 months of support. This allows n -> n + 2 upgrades at arbitrary points in the year, and that is what is needed to bridge over the 4-to-5 polyrhythm (every five upgrades skips a version).

RFC notifications bot (Mar 13 2025 at 18:56):

cfallin edited a comment on PR #42:

After the discussion on this topic today in the Wasmtime biweekly, I thought a little more about the timeline configuration. To recap, in the meeting we discussed a potential requirement that it should be possible for a user to stay up-to-date with LTS releases by upgrading once a year at the same point in the year.

As we noted in the meeting, the current 10-month cadence with 15-month support doesn't meet this requirement: one must upgrade at a point in time when two LTS releases are currently supported (or else this implies one was using an unsupported release); there is a 5-month window every 10 months when this is the case; that 5-month window shifts throughout the calendar over the years.

We discussed a 20-month support window instead, so there are always two LTS releases that are supported. This does mean that one could upgrade at any point during the year. However, it has another issue: one could fall behind if one only upgrades once a year. To see this, observe that with only two LTS releases supported at a time, one must keep up to date by always upgrading n -> n + 1; i.e., never skipping a version (because n and n + 2 are never under support simultaneously). This means that one must upgrade once for every LTS release, and LTS releases happen every 10 months.

To be a little more precise: what will happen is that every 60 months (5 years, the LCM of 10 and 12 months), one will be on version n when the upgrade point in the year comes at the same time as the release of n + 2, and n will go out of support before one can upgrade off of it.

I think there are two ways out if we want to support this requirement:

Adjust to base-12: LTS versions released every 12 months, supported for 24 months. This would definitely allow a fixed-point-in-year upgrade cycle to keep up with a timeframe for the upgrade up to one year, depending on the offset between the release point and one's upgrade schedule.

Adjust to a 3x multiplier: on the 10-month base, this would mean 30 months of support. This allows n -> n + 2 upgrades at arbitrary points in the year, and that is what is needed to bridge over the 5-to-6 polyrhythm (every five upgrades skips a version).

RFC notifications bot (Mar 19 2025 at 21:51):

alexcrichton commented on PR #42:

Ideally I'd like to preserve two properties:

Users, when starting, pick the latest LTS. From then on if the user upgrades once-per-year the user is always on a supported LTS branch.

It's easy to tell which versions are an LTS.

An LTS every 12 months supported for 24 months solves the first item, but I'm only good with multiples of 12 up to 96 (and then 120/144 are outliers). I'm hesitant of a 30 month support window (extending even further beyond 15 months) and have been thinking about the consequences of a 24 month support window for any LTS.

If we release an LTS every 10 months and it's supported for 24 months we'll mostly only have 2 branches at once but sometimes we'll have 3 LTS branches. That's not too bad though and I think that this additionally preserves the property (1) as well. For users though this has an interesting property where sometimes a jump of two LTS releases is required (e.g. 30 -> 50 instead of 30 -> 40). That possibly adds another dimension to this problem of "should the amount of months-of-changes in an LTS upgrade basically be the same. I'd conjecture "yes" probably.

Given that I'm not sure it's possible to preserve (2) where it's a multiple of 10. One other idea though could be "X.0.Y" is a normal release, where "X.1.Y" is an LTS release. We don't otherwise use the "minor" in semver, so it means our releases would be: 36.1.0, 37.0.0, 38.0.0, ... 47.0.0, 48.1.0, 49.0.0, ... That might serve well as easily disambiguating whether something is an LTS or not? (it's subtle though...)

RFC notifications bot (Mar 19 2025 at 21:51):

alexcrichton commented on PR #42:

Oh and if we do 12-based releases I'd say we should retroactively classify wasmtime 24.0.0 as an LTS release and go from there, keep things on multiples-of-12.

RFC notifications bot (Mar 19 2025 at 22:02):

cfallin commented on PR #42:

For what it's worth, Wasmtime 96 will be released in August 2030, i.e. 5.5 years away, so we have a while to get used to the numbering scheme before we get to three-digit multiples of 12 (and we only need to memorize a new one once per year) :-) We could also adopt a typographical scheme when writing out versions like Ubuntu's: "Wasmtime 24 LTS", etc.

I also like the idea of a yearly cadence to the releases: v24 was in August, so we know that August 20th of every year (henceforth declared "Wasmtime Day", a Bytecode Alliance holiday?) we have a new LTS.

RFC notifications bot (Mar 20 2025 at 00:36):

alexcrichton updated PR #42.

RFC notifications bot (Mar 20 2025 at 00:37):

alexcrichton commented on PR #42:

Ok I've now updated wording for once-a-year releases with 24 months of support. With that I think this is ready-to-go, so...

Motion to Finalize

Disposition: Merge

As always, details on the RFC process can be found here: https://github.com/bytecodealliance/rfcs/blob/main/accepted/rfc-process.md#making-a-decision-merge-or-close

RFC notifications bot (Mar 20 2025 at 00:42):

cfallin submitted PR review:

:+1:

RFC notifications bot (Mar 20 2025 at 00:45):

alexcrichton commented on PR #42:

As there has been signoff from representatives of two different BA stakeholder organizations, this RFC is now entering its 10-day

Final Comment Period

and the last day to raise concerns before this RFC merges is 2025-03-29.

Thanks everyone!

(also thanks Nick for giving me a copy/paste template)

RFC notifications bot (Mar 20 2025 at 15:18):

fitzgen submitted PR review:

Thanks for working through this!

RFC notifications bot (Mar 27 2025 at 20:09):

alexcrichton commented on PR #42:

Documentation in prep for this RFC merging: https://github.com/bytecodealliance/wasmtime/pull/10481

RFC notifications bot (Mar 31 2025 at 17:56):

alexcrichton commented on PR #42:

The FCP period has now passed so I'm going to merge, thanks all!

RFC notifications bot (Mar 31 2025 at 17:56):

alexcrichton merged PR #42.

Last updated: Apr 14 2025 at 18:05 UTC