Is there a more convenient way to update the flutter_rust_bridge dependency version?

[Johnny Wang]

Is your feature request related to a problem? Please describe.
flutter_rust_bridge V2 has greatly improved the developer experience. Although it is currently the DEV version, I still use it for development. Is there a more convenient way to update the flutter_rust_bridge dependency?
For example:

flutter_rust_bridge_codegen update

Describe the solution you'd like
Suppose the version I created a few days ago is .dev10 and it is currently .dev21. When I use this command, the relevant dependencies will be updated to: flutter_rust_bridge: 2.0.0-dev.21

Describe alternatives you've considered
Maybe there is already a similar implementation, or it can be modified manually (after all, there may not be many places that need to be modified)?

Additional context
I am very grateful to the developers for their efforts in this project. flutter_rust_bridge has changed a lot of the way I develop flutter

[welcome]

Hi! Thanks for opening your first issue here! 😄

[fzyzcjy]

Yes, this has been discussed in #1432 (@AlienKevin), and may be implemented. It is not hard to upgrade the rust and dart dependencies.

One question is, how are we going to upgrade the flutter_rust_bridge command itself? Users may install it from cargo install, cargo binstall, brew, etc, so it seems not easy to upgrade itself. One way may be we require users to upgrade it manually, but more automation is better... Another way may be adding a shim package, but that adds extra indirection.

[Johnny Wang]

wow, that's cool, thanks

[fzyzcjy]

You are welcome!

No worries, just keep this open as a tracker (since that one's title is "update doc" and the doc was already updated so it was closed)

P.S. I may consider making this logic a part of the generate command, s.t. no manual commands are needed.

[Johnny Wang]

Okay, by the way, how long will it take for the V2 version to be released as the official Release version(I'm not urging )

[fzyzcjy]

I leave it as beta today primarily because as readme.md says:

I want to keep it in beta for a while (though CI has all passed), to allow publishing API breaking changes, and hear your thoughts and suggestions about it!

However, the breaking changes between beta versions is usually minimal IMHO, e.g. some renames, etc. I cannot guarantee it will always be minimal between beta versions, but from today to v2 stable, there seems low probability to have a larger breaking change.
(Once it reaches stable, I cannot make breaking changes except for bumping to v3 - but surely that does not sound good if v2-v3-v4-v5-...v100 happens too quickly ;) )

Except that, beta has all the software engineering things, same as stable, such as (again copying readme.md):

Valgrind & sanitizers (ASAN/MSAN/LSAN) for memory/UB-related bugs, testing per platform per mode, benchmarking, test coverage, post-release, etc, all guaranteed by CI.