Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[14.0.0] Add compatibility shims for Wasmtime 13 CLI #7395

Merged
merged 1 commit into from
Oct 28, 2023
Merged

[14.0.0] Add compatibility shims for Wasmtime 13 CLI #7395

merged 1 commit into from
Oct 28, 2023

Conversation

alexcrichton
Copy link
Member

This is a backport of #7385

@alexcrichton
Add compatibility shims for Wasmtime 13 CLI (bytecodealliance#7385)
3e8dd66 
* Add compatibility shims for Wasmtime 13 CLI

This commit introduces a compatibility shim for the Wasmtime 13 CLI and
prior. The goal of this commit is to address concerns raised in bytecodealliance#7336
and other locations as well. While the new CLI cannot be un-shipped at
this point this PR attempts to ameliorate the situation somewhat through
a few avenues:

* A complete copy of the old CLI parser is now included in `wasmtime` by
  default.
* The `WASMTIME_NEW_CLI=0` environment variable can force usage of the
  old CLI parser for the `run` and `compile` commands.
* The `WASMTIME_NEW_CLI=1` environment variable can force usage of the
  new CLI parser.
* Otherwise both the old and the new CLI parser are executed. Depending
  on the result one is selected to be executed, possibly with a warning
  printed.
* If both CLI parsers succeed but produce the same result, then no
  warning is emitted and execution continues as usual.
* If both CLI parsers succeed but produce different results then a
  warning is emitted indicating this. The warning points to bytecodealliance#7384 which
  has further examples of how to squash the warning. The warning also
  mentions the above env var to turn the warning off. In this situation
  the old semantics are used at this time instead of the new semantics.
  It's intended that eventually this will change in the future.
* If the new CLI succeeds and the old CLI fails then the new semantics
  are executed without warning.
* If the old CLI succeeds and the new CLI fails then a warning is issued
  and the old semantics are used.
* If both the old and the new CLI fail to parse then the error message
  for the new CLI is emitted.

Note that this doesn't add up to a perfect transition. The hope is that
most of the major cases of change at the very least have something
printed. My plan is to land this on `main` and then backport it to the
14.0.0 branch as a 14.0.3 release.

* Wordsmith messages

* Update messages

* More wording updates

* Fix grammar

* More updates
@alexcrichton alexcrichton requested review from a team as code owners October 28, 2023 19:07
@alexcrichton alexcrichton requested review from pchickey and removed request for a team October 28, 2023 19:07
@github-actions github-actions bot added wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime:config Issues related to the configuration of Wasmtime labels Oct 28, 2023
@github-actions
Copy link

Subscribe to Label Action

cc @peterhuene

This issue or pull request has been labeled: "wasmtime:api", "wasmtime:config"

Thus the following users have been cc'd because of the following labels:

  • peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

@github-actions
Copy link

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

  • If you added a new Config method, you wrote extensive documentation for
    it.

    Our documentation should be of the following form:

    Short, simple summary sentence.

More details. These details can be multiple paragraphs. There should be
information about not just the method, but its parameters and results as
well.

Is this method fallible? If so, when can it return an error?

Can this method panic? If so, when does it panic?

# Example

Optional example here.

  • If you added a new Config method, or modified an existing one, you
    ensured that this configuration is exercised by the fuzz targets.

    For example, if you expose a new strategy for allocating the next instance
    slot inside the pooling allocator, you should ensure that at least one of our
    fuzz targets exercises that new strategy.

    Often, all that is required of you is to ensure that there is a knob for this
    configuration option in wasmtime_fuzzing::Config (or one
    of its nested structs).

    Rarely, this may require authoring a new fuzz target to specifically test this
    configuration. See our docs on fuzzing for more details.

  • If you are enabling a configuration option by default, make sure that it
    has been fuzzed for at least two weeks before turning it on by default.

To modify this label's message, edit the .github/label-messager/wasmtime-config.md file.

To add new label messages or remove existing label messages, edit the
.github/label-messager.json configuration file.

Learn more.

@alexcrichton alexcrichton merged commit 196e90d into bytecodealliance:release-14.0.0 Oct 28, 2023
32 checks passed
@alexcrichton alexcrichton deleted the backport-cli branch October 28, 2023 22:44
@tschneidereit tschneidereit mentioned this pull request Oct 29, 2023
Closed
alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request May 11, 2024
@alexcrichton
Remove support for Wasmtime 13-and-prior CLI
68e2c6a 
This commit removes the support in the `wasmtime` CLI for old CLI
options which were present in Wasmtime 13 and prior. This compatibility
was added in bytecodealliance#7385 and backported to the Wasmtime 14 release bytecodealliance#7395.
Wasmtime 14.0.0, which did not have this compatibility shim, was
released on 2023-10-20. Wasmtime 14.0.3, which restored compatibility
with this shim, was released on 2023-10-30. This means that Wasmtime
since 2023-10-30 has been warning users about differences in the old and
new CLI.

This commit will be released with Wasmtime 22 which will means that
users will have had an 8-month transition window for warnings to
migrate. The hope is that this is sufficient but it's also not too too
burdensome to carry for longer if necessary.
@alexcrichton alexcrichton mentioned this pull request May 11, 2024
Merged
alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request May 23, 2024
@alexcrichton
Remove support for Wasmtime 13-and-prior CLI
3ecec9c 
This commit removes the support in the `wasmtime` CLI for old CLI
options which were present in Wasmtime 13 and prior. This compatibility
was added in bytecodealliance#7385 and backported to the Wasmtime 14 release bytecodealliance#7395.
Wasmtime 14.0.0, which did not have this compatibility shim, was
released on 2023-10-20. Wasmtime 14.0.3, which restored compatibility
with this shim, was released on 2023-10-30. This means that Wasmtime
since 2023-10-30 has been warning users about differences in the old and
new CLI.

This commit will be released with Wasmtime 22 which will means that
users will have had an 8-month transition window for warnings to
migrate. The hope is that this is sufficient but it's also not too too
burdensome to carry for longer if necessary.
github-merge-queue bot pushed a commit that referenced this pull request May 23, 2024
@alexcrichton
Remove support for Wasmtime 13-and-prior CLI (#8597)
ffd6bb5 
This commit removes the support in the `wasmtime` CLI for old CLI
options which were present in Wasmtime 13 and prior. This compatibility
was added in #7385 and backported to the Wasmtime 14 release #7395.
Wasmtime 14.0.0, which did not have this compatibility shim, was
released on 2023-10-20. Wasmtime 14.0.3, which restored compatibility
with this shim, was released on 2023-10-30. This means that Wasmtime
since 2023-10-30 has been warning users about differences in the old and
new CLI.

This commit will be released with Wasmtime 22 which will means that
users will have had an 8-month transition window for warnings to
migrate. The hope is that this is sufficient but it's also not too too
burdensome to carry for longer if necessary.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@cfallin cfallin cfallin approved these changes

@pchickey pchickey Awaiting requested review from pchickey pchickey is a code owner automatically assigned from bytecodealliance/wasmtime-core-reviewers

Assignees
No one assigned
Labels
wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime:config Issues related to the configuration of Wasmtime
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@alexcrichton @cfallin