diff options
| author | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2020-05-14 10:23:34 +0100 |
|---|---|---|
| committer | GitHub <[email protected]> | 2020-05-14 10:23:34 +0100 |
| commit | 5148d6dc66d80b375a98143dfbb556ec675bbffc (patch) | |
| tree | fb803ca1ef8185c0e4738d41a8f0e74c0108324a /crates/ra_assists/src/ast_transform.rs | |
| parent | 6fde7f1b6bb30481a38c3346729dde9bd1b42c1a (diff) | |
| parent | 9f0a7eb97b4e047cebbe51ffd6f9e2092dd63e00 (diff) | |
Merge #4405
4405: Make some stuff public so that they can be reused by other tools r=pksunkara a=pksunkara
So, my little experiment of building a code analysis tool using rust-analyzer is successful. I am going to proceed to build the tool now. This PR makes the needed things public.
I know there were some things about trying to change stuff regarding loading workspaces, which would make it more easier for other tools to reuse. But, until then, it should be okay using this `load_cargo` fn.
Btw, if I were publish my tool, I would need the `ra` crates to be released. Since @matklad told me that he doesn't want to care about breaking stuff, I would propose the following.
Every monday, during the weekly release, we release a new pre v1 minor version of all the crates. That way, we don't need to care about breaking stuff but still have rust-analyzer on crates.io.
I made https://github.com/pksunkara/cargo-workspaces to help release workspace crates easily.
So, coming week, we start with `0.1.0`, then week after that, we release `0.2.0` and then `0.3.0` etc.. until we decide on `1.0.0` which is probably when the compiler team also starts using the crates. There is no limit to the minor versions (we can even have `0.150.0` or `0.1500.0`), so I don't see anything wrong with this strategy.
Co-authored-by: Pavan Kumar Sunkara <[email protected]>
Diffstat (limited to 'crates/ra_assists/src/ast_transform.rs')
0 files changed, 0 insertions, 0 deletions