Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR enables spec shaking v2 by default in soroban-sdk, updating tests and CI workflows to treat v2 as the baseline behavior while keeping v1 available via default-features = false.
Changes:
- Add
experimental_spec_shaking_v2tosoroban-sdk’s default feature set. - Update spec shaking test crates so v2 uses defaults and v1 explicitly disables default features.
- Simplify external-repo CI workflows by removing the v1/v2 feature-matrix testing.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
soroban-sdk/Cargo.toml |
Enables spec shaking v2 via default features. |
soroban-sdk/src/_features.rs |
Updates feature docs to reflect v2 default and v1 opt-out. |
tests/spec_shaking_v2/Cargo.toml |
Removes explicit v2 feature flag since it’s now default. |
tests/spec_shaking_v1/Cargo.toml |
Disables default features to keep v1 behavior. |
.github/workflows/test-with-soroban-examples.yml |
Removes v2 toggle matrix and related patching steps. |
.github/workflows/test-with-openzeppelin-stellar-contracts.yml |
Removes v2 toggle matrix and related patching steps. |
Comments suppressed due to low confidence (1)
tests/spec_shaking_v1/Cargo.toml:20
[dependencies]disables default features to force spec shaking v1, but[dev-dependencies]reintroducessoroban-sdkwithoutdefault-features = false. Because Cargo unifies features for the same dependency across dependency kinds when running tests, this can end up enabling the default feature set (and therefore spec shaking v2) for this crate’scargo testbuild, undermining the intent of the v1 test setup. Consider addingdefault-features = falseto the[dev-dependencies] soroban-sdkentry as well (while still enablingtestutils).
soroban-sdk = {path = "../../soroban-sdk", default-features = false}
test_spec_lib = {path = "../spec_lib"}
[dev-dependencies]
soroban-sdk = {path = "../../soroban-sdk", features = ["testutils"]}
soroban-spec = {path = "../../soroban-spec"}
…d test outputs to reflect spec shaking v2 being enabled by default. update expanded tests for spec shaking v2 default
dmkozh
approved these changes
Apr 1, 2026
sisuresh
approved these changes
Apr 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Add
experimental_spec_shaking_v2to the default feature set insoroban-sdk, enabling the feature by default.Why
So far feedback is either neutral or positive.
The feature significantly improves the spec shaking process of the sdk.
Spec shaking v2 has been available as an experimental feature last month. The v26 release candidate will be created soon, and then it will become stable in 1 month. In total that provides approx 50 days for the experimental feature to be available for developers to provide feedback.
The feature name with its
experimental_prefix is preserved for backwards compatibility and will be removed in v27 when v2 becomes the only spec shaking implementation supported.If negative feedback arises while v26 is in release candidate we can revisit the roll out. While v26 is in stable people can still disable v2 if needed if edge cases are discovered, and the final roll out targeting v27 can be delayed if needed.