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.

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

Upgrade Soroban env to latest patch #356

Merged
merged 4 commits into from
Jan 31, 2025
Merged

Upgrade Soroban env to latest patch #356

merged 4 commits into from
Jan 31, 2025

Conversation

Shaptic
Copy link
Contributor

@Shaptic Shaptic commented Jan 30, 2025

What

Bump dependencies to their latest versions and run cargo update.

Why

Self-explanatory.

@Shaptic Shaptic requested review from 2opremio and dmkozh January 30, 2025 18:47
Cargo.toml Outdated Show resolved Hide resolved
@Shaptic
Copy link
Contributor Author

Shaptic commented Jan 31, 2025

@dmkozh looks like stellar/rs-soroban-env@5a28b69 was a breaking change to soroban-simulation: what's the appropriate resolution in this preflight call?

Or is it more correct to remove unstable-next-api from our toml?


Edit: Went with the second option, which changes the question: what should it be in the future when we're ready to use the next API?

@Shaptic Shaptic merged commit 755d81f into main Jan 31, 2025
19 checks passed
@Shaptic Shaptic deleted the bump-env branch January 31, 2025 19:53
@dmkozh
Copy link
Contributor

dmkozh commented Jan 31, 2025

was a breaking change to soroban-simulation

Yes, it's expected to be breaking, which is whyunstable-next-api guard is used. I'm surprised this feature is enabled by default in RPC. FWIW the particular change is done in order to allow addressing #344 in RPC.

I think it would make sense to remove this feature from RPC (as it has to be added intentionally), but it also makes sense to update to just 22.1.0.

@dmkozh
Copy link
Contributor

dmkozh commented Jan 31, 2025

Edit: Went with the second option, which changes the question: what should it be in the future when we're ready to use the next API?

I think a separate PR should be created for adaptation to the API changes. Basically the idea behind unstable-next-api is to clean it up on every major release and I think it makes sense for clients to remove it when bumping the major version of env. Then for the work in-between the releases it can be enabled in order to adopt the API changes without waiting for the major release.

@Shaptic
Copy link
Contributor Author

Shaptic commented Jan 31, 2025

Yep makes sense! We'll refactor for the new API as part of P23 work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants