-
Notifications
You must be signed in to change notification settings - Fork 492
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: allow identifierBase to be false #548
feat: allow identifierBase to be false #548
Conversation
…intentifiers without appending .0
A "disable" boolean is often very confusing because it's turning something off when it's true. We already have a flag to change this number, perhaps supporting |
157e260
to
fda7e36
Compare
…Prerelease Identifier Base parameter
fda7e36
to
14a3913
Compare
A very good start. Just some minor copy and code quality feedback. |
test/fixtures/increments.js
Outdated
['1.2.3-dev.bar', 'prerelease', '1.2.3-dev', false, 'dev', false], | ||
['1.2.0', 'preminor', '1.3.0-dev', false, 'dev', false], | ||
['1.2.3-1', 'preminor', '1.3.0-dev', false, 'dev', false], | ||
['1.2.3-dev', 'prerelease', '1.2.3-dev.1', false, 'dev', false], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nlf what do you think about this? If they have said "increase the prerelease" but also asked for there not to be a prerelease base, do we default to 1 or should we throw?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my gut reaction is we should throw because they've asked for us to do something that doesn't make sense. going from no number to adding a number when we've been asked to not add numbers feels wrong
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, let's throw in this situation. No more guessing user intent!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just to clarify do we want to throw also in:
['1.2.0', 'prerelease', '1.2.1-1', false, '', false],
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oooh good point. We sure do! "increase the prerelease with no identifier and no identifierBase" sure sounds impossible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i updated it to throw on both cases
Can you add the tests from #550 to this PR? |
Really useful new feature, thanks! |
What
Added Disable Prerelease Identifier Base flag for creating prerelease identifiers without appending
.0
/.1
Improved
Prerelease Identifier Base
to use it when identifier is not set (1.0.0-{Identifier Base}) and adds description to cli help for-n
flagWhy
Version
1.0.0-something
is valid Semantic Version and its not necessary to have "build" number for identifiers that have only one/ first build, changes reflect that so if another prerelease is created with same identifier the "build" number will be append according Prerelease Identifier Base argumentReferences
Fixes #441
Improves #532