Minor clarity edits to release process docs (#11823)

I ran across some words and things weren't 100% accurate, so I tried to
make them more accurate.

Don't break cwasm ABIs in patch releases by default (#11687)

This commit is an update to our cwasm-version-matching logic to
take #11685 into account. To me it feels reasonable to expect that patch

Don't break cwasm ABIs in patch releases by default (#11687)

This commit is an update to our cwasm-version-matching logic to
take #11685 into account. To me it feels reasonable to expect that patch
releases 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 in
more 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 release
is "forgotten" and won't be compared.

This commit also updates documentation for patch releases to indicate
that this should be double-checked on patch releases. Furthermore we can
always update the string ourselves manually (e.g. to include a ".2" at
the end or something like that) if an ABI break is actually needed. This
mostly just changes the default of patch releases by default don't break
ABI but we still can if we really need to for a particular issue.

show more ...

Add documentation for Wasmtime's LTS releases (#10481)

* Add documentation for Wasmtime's LTS releases

With Wasmtime's [LTS
releases](https://github.com/bytecodealliance/rfcs/pull/42) this commit
d

Add documentation for Wasmtime's LTS releases (#10481)

* Add documentation for Wasmtime's LTS releases

With Wasmtime's [LTS
releases](https://github.com/bytecodealliance/rfcs/pull/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

show more ...

Document a Wasmtime-specific vulnerability runbook (#9433)

This commit codifies the process [documented
here](https://github.com/bytecodealliance/rfcs/blob/main/accepted/vulnerability-response-runbo

Document a Wasmtime-specific vulnerability runbook (#9433)

This commit codifies the process [documented
here](https://github.com/bytecodealliance/rfcs/blob/main/accepted/vulnerability-response-runbook.md)
in the Wasmtime repository as it relates to Wasmtime itself. There's
also 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 with
Wasmtime-specific information and flesh out a few minor steps we're
following that are "extra" here too.

show more ...

Refactor how release notes are managed (#8680)

* Refactor how release notes are managed

This commit updates how Wasmtime manages release notes across released
versions of Wasmtime. One of the most

Refactor how release notes are managed (#8680)

* Refactor how release notes are managed

This commit updates how Wasmtime manages release notes across released
versions of Wasmtime. One of the most onerous parts about releases right
now is writing release notes in all the locations and making sure
they're all up-to-date and in-sync. This is inevitably forgotten in some
cases and various pieces will slip through the cracks. The basic idea of
this PR is to change our release notes to only document the release
branch that they're on. All historical release notes are relegated to
historical branches.

With this change there's no longer any need to backport or forward-port
release notes for any changes. Instead release notes are written once
on one branch and that's it.

The major downside of this change is that there's no easy way to get a
bird's eye view of all release notes for Wasmtime any more. If necessary
that could theoretically be automated in the future (like
https://releases.rs/), but for now this feels like an acceptable
compromise to make releases much easier.

The contents of this PR are to update `RELEASES.md` with back-links to
historical release notes as well as the various pieces of automation we
have about managing release notes.

* Add more notes about the release process

* Fix a typo

* Make it more obvious that patch releases are documented

show more ...

Add comments about updating release dates (#8022)

* Add comments about updating release dates

* Add a note about forward-porting release notes

docs: fix typos (#7741)

Update security release documentation slightly (#5940)

This modernizes our process doc a bit with what I've been doing for the
last security release and the upcoming one as well.

Fixup release documentation (#3988)

* Fill out some missing comments on the workflow itself
* Fix some formatting in the book to properly render sub-bullets

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

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

show more ...

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

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

show more ...

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% automate

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

show more ...

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

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.

show more ...

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 whe

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.

show more ...

Update contributing docs with new script name

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.

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

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.

show more ...

Document and codify the release process

The `wasmtime` release procees seems like it's been a bit ad-hoc up to
this point, so I figured it'd be good to try to document what we do
today and codify wh

Document and codify the release process

The `wasmtime` release procees seems like it's been a bit ad-hoc up to
this point, so I figured it'd be good to try to document what we do
today and codify what should be done as well as a form of release
checklist.

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 version
of `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 we
can avoid these sorts of accidental issues in the future!

[release]: https://github.com/bytecodealliance/wasmtime/runs/434690272

show more ...