You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.jsonversion 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.
The text was updated successfully, but these errors were encountered:
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 whatrelease
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 IIRCrelease
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.
The text was updated successfully, but these errors were encountered: