An argument against the <type> CLI parameter

[Qix-]

Would it be better UX to eliminate that parameter and instead bump based off the broadest "type" the user selects when classifying commits?

For example, if I go through the latest commits since the tag with the current package.json version tag (e.g. git log $(cat package.json | jq '.version')..HEAD) - which I assume is what release is doing (conceptually) - and specify only patch-level commits, then the release would be a patch release.

Alternatively if I specified a few patches and a few minors, then the "broadest" type is a minor, so therefore a minor release occurs - and so on with major releases.

---

The use case I'm admittedly not hitting quite yet but probably will is a potentially major release of debug: I'm not sure what changes there are since the last release at first glance and I know that I'd be frustrated if I went through a bunch of commits I'm not immediately familiar with under the assumption it's a minor patch and it ends up being a major (which IIRC release prevents you from specifying a type broader than the currently specified type).

This has the (IMO positive) side effect of keeping release a run-and-done utility requiring little to no parameters to run it.

Just a thought. It was something that I thought a bit about back at ZEIT that I never got the chance to bring up, and it just crossed my mind.