-
Notifications
You must be signed in to change notification settings - Fork 76
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
enable independent releases of soroban-rpc and soroban-cli #1115
Comments
All of the Rust repos in the @stellar org share the same release process. Rather than introduce a new release process for the CLI to support releasing the CLI + RPC independently from within the same repo, I'd like to see it maintain the same release process that the Rust repos use. Rust projects are not trivial to release, and over time having a single release process for all our Rust projects will help us maintain a consistent and secure release process for these projects. |
I also think that by bundling the two together we're placing unnecessary emphasis on the soroban-cli being a client of the RPC, when over time I think the CLI is going to encompass much much more, and it's functionality interacting with the RPC will just be one aspect. |
Agreed, I believe the plan is to restructure this repo. CLI will live in its own repo, be renamed from Soroban CLI to Stellar CLI, has a README available at the top level, and has its own release cadence. |
I split the RPC into its own crate in this PR #1065. Which is the first step toward your last point. |
+1. For the sake of preserving the most git history and git sha's possible, and github binary releases, I suggest we keep this repo as the soroban-cli, because this repo started out as the soroban-cli repo and has release processes htat upload artifacts that are attached to this repo. Later on soroban-rpc was moved into this repo and it piggy backed on the soroban-cli's release process. |
As of now, we're able to release Soroban RPC separately from CLI. Please refer to this tracking issue for what's left in terms of clean up |
What problem does your feature solve?
Currently, RPC and CLI are always versioned together when released. These are different products with different release lifecycles. It's likely that CLI will have a tendency to iterate faster than RPC as soroban matures. However, if CLI-only changes are made, RPC still gets version bumped. This means that semantic versioning can't be properly followed for both of these tools.
What would you like to see?
A release process / CD pipeline that allows us to independently version and release soroban-rpc and soroban-cli.
What alternatives are there?
The text was updated successfully, but these errors were encountered: