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
{{ message }}
Repository navigation
CLI accepts invalid increment specifiers with -i/--increment and treats them as 'patch' #108
changed the title [-]CLI accepts invalid increment specifiers with -i/--increment and treats them as [/-][+]CLI accepts invalid increment specifiers with -i/--increment and treats them as 'patch'[/+]on Oct 23, 2014
@mklement0 Thanks for the feedback. I closed this issue as a first pass through this repo, so maybe "by design" was the wrong choice of words. The code makes it clear that any invalid values passed to -i are ignored but I agree that erroring is a good idea.
For this project I believe in a very cautious approach to versioning, so I think this would be a breaking change so I'm going to tag it as such. I don't have any immediate plans to release a major version but surfacing this as a breaking change will help to batch this in when it's time.
Reacted by Michael Klement, Jordan Harband and Marc Bernard
@lukekarrys would it be acceptable in the current v7 to add a console.warn about what is happening, and that this behavior might go away in a future version? This preserves the current behavior (including the ability to redirect or pipe the output) whilst still explaining what is happening.
Activity
[-]CLI accepts invalid increment specifiers with -i/--increment and treats them as [/-][+]CLI accepts invalid increment specifiers with -i/--increment and treats them as 'patch'[/+]lukekarrys commentedon Apr 10, 2022
This is working by design. The default value of
-iispatchand invalid versions are filtered out of the input.mklement0 commentedon Apr 28, 2022
Quietly accepting invalid input is problematic.
Another way of putting it: if this is by design, please reconsider the design.
Consider reporting an error if an invalid
-iargument is specified.lukekarrys commentedon Jun 9, 2022
@mklement0 Thanks for the feedback. I closed this issue as a first pass through this repo, so maybe "by design" was the wrong choice of words. The code makes it clear that any invalid values passed to
-iare ignored but I agree that erroring is a good idea.For this project I believe in a very cautious approach to versioning, so I think this would be a breaking change so I'm going to tag it as such. I don't have any immediate plans to release a major version but surfacing this as a breaking change will help to batch this in when it's time.
pjohnmeyer commentedon May 3, 2026
@lukekarrys would it be acceptable in the current v7 to add a
console.warnabout what is happening, and that this behavior might go away in a future version? This preserves the current behavior (including the ability to redirect or pipe the output) whilst still explaining what is happening.pjohnmeyer commentedon May 10, 2026
@owlstronaut are you sure we want this closed? The changes I made in #859 are only a stepping stone to the v8 changes being tracked.
owlstronaut commentedon May 11, 2026
oh thanks :) things are hectic 😆