Sebastian Thiel

Custom registries aren't what I had in mind when writing this program, hence it's very unsupported. New features can be added by the community, but [as can be followed-up on...

`gitoxide` crates are already suffering from this issue, as `auto-publish-of-stable-crates` is default-off now, just to avoid surprises, but the result of the operation might be then be somewhat incorrect (i...

You can probably try that locally in a project that would need it. It's also the only place that seems to filter by kind, so I'd say it's indeed promising.

`dev-dependencies` that are also in the workspace must use `{ path = "" }` without mentioning any `version`. Otherwise it definitely breaks.

That's great research right there and I can assure you that nothing has been missed. This oddity was intentional knowing that I could write a tool that just suits me,...

> First off, this crate is awesome. It is _so close_ to being a does-what-you-want publish tool for cargo crates. Thank you! Even though I'd use `cargo smart-release` with caution...

Thanks for the suggestion, here is my thoughts. > 2. Add packaging smart-release. This could be a lot of work, or it could be not possible within reason, because different...

> I'm leaning towards lifecycle hooks being the best option, because I think it would allow for the most amount of flexibility on both the smart-release side and the user...

Indeed, this is already implemented and "prepare" can be achieved by adding the various `--no-*` flags, like `--no-publish` and `--no-push`, maybe more. Then one can repeat the release without the...

Oh, I see. I think the first line should also be `--no-tag` - that way it should still detect changes in the final `smart-release` call which then should do the...