en Copyright 2015 Java http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#3c93e2b5 Minor clarity edits to release process docs (#11823)I ran across some words and things weren't 100% accurate, so I tried tomake them more accurate. List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Thu, 09 Oct 2025 19:30:19 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#8218e903 Don't break cwasm ABIs in patch releases by default (#11687)This commit is an update to our cwasm-version-matching logic totake #11685 into account. To me it feels reasonable to expect that patchreleases of Wasmtime by default do not affect the ABI of `*.cwasm`artifacts and thus we should allow by default loading previous versions.This can help embedders avoid recompiles and can additionally assist inmore quickly deploying security updates as recompilation is unnecessary.The concrete change in this commit is that instead of baking in`CARGO_PKG_VERSION` into the cwasm artifact instead`CARGO_PKG_VERSION_MAJOR` is baked in. This means that the patch releaseis "forgotten" and won't be compared.This commit also updates documentation for patch releases to indicatethat this should be double-checked on patch releases. Furthermore we canalways update the string ourselves manually (e.g. to include a ".2" atthe end or something like that) if an ABI break is actually needed. Thismostly just changes the default of patch releases by default don't breakABI but we still can if we really need to for a particular issue. List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Thu, 11 Sep 2025 21:50:21 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#2de55ccf Add documentation for Wasmtime's LTS releases (#10481)* Add documentation for Wasmtime's LTS releasesWith Wasmtime's [LTSreleases](https://github.com/bytecodealliance/rfcs/pull/42) this commitdocuments the various process changes and updates to our releaseprocess. Additionally some improvements are made to the releasedocumentation with respect to showing current versions.* Refactor some backport criteria docs* Review comments List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Mon, 31 Mar 2025 18:49:16 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#866ede95 Document a Wasmtime-specific vulnerability runbook (#9433)This commit codifies the process [documentedhere](https://github.com/bytecodealliance/rfcs/blob/main/accepted/vulnerability-response-runbook.md)in the Wasmtime repository as it relates to Wasmtime itself. There'salso a few minor changes from recent advisories such as:* We'll no longer use the publish-the-changes-from-the-advisory feature from GitHub. That basically just doesn't work any more.* PRs will instead be manually created to have CI run on them to weed out any issues.* Details about preparing the `main` branch ahead of the release are interleaved with the rest of the runbook.The intention is to supplement the official runbook withWasmtime-specific information and flesh out a few minor steps we'refollowing that are "extra" here too. List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Thu, 10 Oct 2024 16:48:43 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#14226457 Refactor how release notes are managed (#8680)* Refactor how release notes are managedThis commit updates how Wasmtime manages release notes across releasedversions of Wasmtime. One of the most onerous parts about releases rightnow is writing release notes in all the locations and making surethey're all up-to-date and in-sync. This is inevitably forgotten in somecases and various pieces will slip through the cracks. The basic idea ofthis PR is to change our release notes to only document the releasebranch that they're on. All historical release notes are relegated tohistorical branches.With this change there's no longer any need to backport or forward-portrelease notes for any changes. Instead release notes are written onceon one branch and that's it.The major downside of this change is that there's no easy way to get abird's eye view of all release notes for Wasmtime any more. If necessarythat could theoretically be automated in the future (likehttps://releases.rs/), but for now this feels like an acceptablecompromise to make releases much easier.The contents of this PR are to update `RELEASES.md` with back-links tohistorical release notes as well as the various pieces of automation wehave about managing release notes.* Add more notes about the release process* Fix a typo* Make it more obvious that patch releases are documented List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Thu, 23 May 2024 16:35:23 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#42f218d8 Add comments about updating release dates (#8022)* Add comments about updating release dates* Add a note about forward-porting release notes List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Wed, 28 Feb 2024 23:18:01 +0000 Trevor Elliott <telliott@fastly.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#523bc959 docs: fix typos (#7741) List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Wed, 03 Jan 2024 15:53:56 +0000 vuittont60 <81072379+vuittont60@users.noreply.github.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#3782ce73 Update security release documentation slightly (#5940)This modernizes our process doc a bit with what I've been doing for thelast security release and the upcoming one as well. List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Mon, 06 Mar 2023 17:19:53 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#35377bd3 Fixup release documentation (#3988)* Fill out some missing comments on the workflow itself * Fix some formatting in the book to properly render sub-bullets List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Tue, 05 Apr 2022 19:14:44 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#c89dc551 Add a two-week delay to Wasmtime's release process (#3955)* Bump to 0.36.0 * Add a two-week delay to Wasmtime's release process This commit is a proposal to update Wasmtime's release process with a two-week delay from branching a release until it's actually officially released. We've had two issues lately that came up which led to this proposal: * In #3915 it was realized that changes just before the 0.35.0 release weren't enough for an embedding use case, but the PR didn't meet the expectations for a full patch release. * At Fastly we were about to start rolling out a new version of Wasmtime when over the weekend the fuzz bug #3951 was found. This led to the desire internally to have a "must have been fuzzed for this long" period of time for Wasmtime changes which we felt were better reflected in the release process itself rather than something about Fastly's own integration with Wasmtime. This commit updates the automation for releases to unconditionally create a `release-X.Y.Z` branch on the 5th of every month. The actual release from this branch is then performed on the 20th of every month, roughly two weeks later. This should provide a period of time to ensure that all changes in a release are fuzzed for at least two weeks and avoid any further surprises. This should also help with any last-minute changes made just before a release if they need tweaking since backporting to a not-yet-released branch is much easier. Overall there are some new properties about Wasmtime with this proposal as well: * The `main` branch will always have a section in `RELEASES.md` which is listed as "Unreleased" for us to fill out. * The `main` branch will always be a version ahead of the latest release. For example it will be bump pre-emptively as part of the release process on the 5th where if `release-2.0.0` was created then the `main` branch will have 3.0.0 Wasmtime. * Dates for major versions are automatically updated in the `RELEASES.md` notes. The associated documentation for our release process is updated and the various scripts should all be updated now as well with this commit. * Add notes on a security patch * Clarify security fixes shouldn't be previewed early on CI List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Fri, 01 Apr 2022 18:11:10 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#00feefe9 Change the bump-version workflow's schedule (#3512)* Change the bump-version workflow's schedule Either I don't understand cron or GitHub doesn't understand cron. It's not clear which. I think that https://github.com/bytecodealliance/wasmtime/pull/3511 may have fallen within our schedule but it was supposed to be on a weekday. Otherwise https://github.com/bytecodealliance/wasmtime/pull/3499 was certainly spurious. This commit moves to a simpler "just do it on the same day each month" and we can manually figure out weekdays and such. Hopefully this should reduce the number of spurious PRs we're getting to bump versions. This also removes the script to force a version bump since I found a button on the GitHub UI to do the same thing. Additionally I've updated the patch-release documentation to use this button. Note that this button takes inputs as well which means we can further automate patch releases to look even more like normal release process, differing only in one part of the argument used to trigger the workflow. * Fix a typo List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Mon, 08 Nov 2021 16:37:53 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#807b528b Automate more of Wasmtime's release process (#3422)* Automate more of Wasmtime's release process This change revamps the release process for Wasmtime and intends to make it nearly 100% automated for major release and hopefully still pretty simple for patch releases. New workflows are introduced as part of this commit: * Once a month a PR is created with major version bumps * Specifically hinted commit messages to the `main` branch will get tagged and pushed to the main repository. * On tags we'll now not only build releases after running CI but additionally crates will be published to crates.io. In conjunction with other changes this means that the release process for a new major version of Wasmtime is simply merging a PR. Patch releases will involve running some steps locally but most of the nitty-gritty should be simply merging the PR that's generated. * Use an anchor in a regex List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Tue, 26 Oct 2021 15:25:40 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#b553d843 Change how security advisories work on CI (#3461)Before this commit we actually have two builders checking for security advisories on CI, one is `cargo audit` and one is `cargo deny`. The `cargo deny` builder is slightly different in that it checks a few other things about our dependency tree such as licenses, duplicates, etc. This commit removes the advisory check from `cargo deny` on CI and then moves the `cargo audit` check to a separate workflow. The `cargo audit` check will now run nightly and will open an issue on the Wasmtime repository when an advisory is found. This should help make it such that our CI is never broken by the publication of an advisory but we're still promptly notified whenever an advisory is made. I've updated the release process notes to indicate that the open issues should be double-checked to ensure that there are no open advisories that we need to take care of. List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Tue, 19 Oct 2021 15:12:36 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#978070c0 Verify crates are publish-able on CI (#2036)This commit updates our CI to verify that all crates are publish-able at all times on every commit. During the 0.19.0 release we found another case where the crates as they live in this repository weren't publish-able, so the hope is that this no longer comes up again! The script added in this commit also takes the time/liberty to remove the existing bump/publish scripts and instead replace them with one Rust script originally sourced from wasm-bindgen. The intention of this script is that it has three modes: * `./publish bump` - bumps version numbers which are sent as a PR to get reviewed (probably with a changelog as well) * `./publish verify` - run on CI on every commit, builds every crate we publish as if it's being published to crates.io, notably without raw access to other crates in the repository. * `./publish publish` - publishes all crates to crates.io, passing the `--no-verify` flag to make this a much speedier process than it is today. List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Fri, 17 Jul 2020 21:19:35 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#612b806a Update contributing docs with new script name List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Tue, 17 Mar 2020 17:13:09 +0000 Nick Fitzgerald <fitzgen@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#fbe29da5 Miscelaneous docs updates and fixes. (#1249)Update references to things in CraneStation which have moved, WASI documentation which has moved to the WASI repo, and fix a few typos. List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Sun, 08 Mar 2020 15:11:17 +0000 Dan Gohman <sunfish@mozilla.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#35d5c6bd Add a `RELEASES.md` file to track release notes (#1011)This is intended to be a form of release notes for wasmtime where we can keep track of what's changed over time in a more dense way than `git log` that should be interesting for most users. List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Thu, 27 Feb 2020 19:00:13 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/docs/contributing-release-process.md#12cff023 Document and codify the release processThe `wasmtime` release procees seems like it's been a bit ad-hoc up tothis point, so I figured it'd be good to try to document what we dotoday and codify what should be done as well as a form of releasechecklist.I've noticed that we have a number of releases (like v0.11.0) but the`Cargo.toml` files in the repository don't reflect the current versionof `wasmtime`. Additionally I've noticed that the [most recent release]ended up having failed tests because `Cargo.toml` was modified but`Cargo.lock` wasn't updated. I'm hoping that by having a checklist wecan avoid these sorts of accidental issues in the future![release]: https://github.com/bytecodealliance/wasmtime/runs/434690272 List of files: /wasmtime-44.0.1/docs/contributing-release-process.md Mon, 24 Feb 2020 18:43:00 +0000 Alex Crichton <alex@alexcrichton.com>