| CARVIEW |
Navigation Menu
-
Notifications
You must be signed in to change notification settings - Fork 23
Add an LTS channel of release for Wasmtime #42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an LTS channel of release for Wasmtime #42
Conversation
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.
|
Some more bits from bytecodealliance/wasmtime#10161 I want to fill in:
|
fitzgen
left a comment
fitzgen
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for writing this up! I am in favor.
accepted/wasmtime-lts.md
Outdated
| - What is the exact process by which release automation does a "dry run" every | ||
| so often? And how frequently is "every so often"? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
accepted/wasmtime-lts.md
Outdated
| - Supporting a release for 20 versions is, as of now, probably a little | ||
| ambitious. Should we include wording saying that this is sort of a "trial run" | ||
| and we reserve the right to decrease the support window? Should we start with | ||
| something smaller like supporting for 12 months first and then reevaluate in | ||
| the future if it's worth widening to 20? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me, updated đź‘Ť
Just a minor call-out for bytecodealliance/rfcs#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:
|
|
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.
|
|
Ideally I'd like to preserve two properties:
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...) |
|
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. |
|
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. |
|
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 FinalizeDisposition: 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 |
cfallin
left a comment
cfallin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
đź‘Ť
|
As there has been signoff from representatives of two different BA stakeholder organizations, this RFC is now entering its 10-day Final Comment Periodand 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) |
fitzgen
left a comment
fitzgen
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working through this!
This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
…10438) This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
…10438) This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
…10438) This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
…10438) This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
With Wasmtime's [LTS releases](bytecodealliance/rfcs#42) this commit documents the various process changes and updates to our release process. Additionally some improvements are made to the release documentation with respect to showing current versions.
With Wasmtime's [LTS releases](bytecodealliance/rfcs#42) this commit documents the various process changes and updates to our release process. Additionally some improvements are made to the release documentation with respect to showing current versions.
|
Documentation in prep for this RFC merging: bytecodealliance/wasmtime#10481 |
With Wasmtime's [LTS releases](bytecodealliance/rfcs#42) this commit documents the various process changes and updates to our release process. Additionally some improvements are made to the release documentation with respect to showing current versions.
|
The FCP period has now passed so I'm going to merge, thanks all! |
* Add documentation for Wasmtime's LTS releases With Wasmtime's [LTS releases](bytecodealliance/rfcs#42) this commit documents the various process changes and updates to our release process. Additionally some improvements are made to the release documentation with respect to showing current versions. * Refactor some backport criteria docs * Review comments
Summarize the outcome of bytecodealliance/rfcs#42 and link to the documentation we now have on LTS releases.
Summarize the outcome of bytecodealliance/rfcs#42 and link to the documentation we now have on LTS releases.
Labels
3 participants
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:
Rendered