-
Notifications
You must be signed in to change notification settings - Fork 798
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
Feature/add preid param for semver #83
Feature/add preid param for semver #83
Conversation
default: false, | ||
global: true | ||
}) | ||
.option('pre-id', { |
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 think this should be called "tag", as https://docs.npmjs.com/cli/publish
Also you need to change the final npm publish
information
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.
Defining a tag when publishing is the same like a git tag. pre-release and pre-id are one part of the tag. See http://semver.org/ for more infos.
About the publish, yes but this is in the users scope. If you want to use alpha, beta instead of dist-tags f.e, it should be configurable and the user can choose how and where he publishes what. That's one of the great things of standard-version, you can also use if for a non node project.
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.
Where did you see the name "pre-id"?
About the publish, yes but this is in the users scope.
What I mean is just to display a recommendation. Because right now it says npm publish
without a tag. Displaying --tag
would be a better recommendation.
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'm not completely sure about the relationship between git tag and npm publish tag. It doesn't look the same to me. npm publish by default uses "latest" tag.
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.
Sorry, @stevemao you are right. The npm publish tag is not the same like the git tag. I will also rename it to tag.
I wonder if we could leverage |
@@ -1,2 +1,3 @@ | |||
node_modules | |||
.nyc_output | |||
.idea |
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.
Don't do unrelated changes :)
After using it for a while, I found two bugs that need's to be fixed before this can be merged. One is nearly fixed, the second one needs some discussion. Should prereleases be shown in the changelog? |
feat(args): --next (-x) --actual (-a) now print out the version without doing something
What bugs? Can you remove all unrelated changes and separate different things into different issues? |
The bugs should be fixed with the two latest commits. If you tried to create a prerelease and added a new feature, it did not increase the minor version instead, it just increased the prerelease, which was wrong. The only unrelated thing right now is the next, actual feature. I could remove it, wait until the PR is merged and read it, but its just 15 lines of code. In my opinion, it's not worth the time. But if you insist, I will do it. Should I remove the changelog entry and downgrade the version to 2.4.0 again? |
I'd suggest you to create another PR for other things. You also need to add tests. Also too many unnecessary whitespace changes. |
@stevemao: What about the package.json and CHANGELOG.md? I think it does not make sense to generate them in the PR, right? |
Yeah, as atomic as possible :) |
Should be ready now. Thanks for your help! |
checkpoint('bumping version in package.json from %s to %s', [pkg.version, newVersion]) | ||
pkg.version = newVersion | ||
fs.writeFileSync(pkgPath, JSON.stringify(pkg, null, 2) + '\n', 'utf-8') | ||
} else { | ||
checkpoint('skip version bump on first release', [], chalk.red(figures.cross)) | ||
} | ||
|
||
outputChangelog(argv, function () { | ||
// only commit the package.json on prerelease |
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.
Why?
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.
So the version for a prerelease is bumped, but no docs are generated. This only happens when the release is stable. It would flood the changelog otherwise.
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.
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.
@stvnwrgs, I think I'm with @stevemao. Let's generate a CHANGELOG for pre-releases, with this caveat:
It would be neat if there was eventually logic that could once v1.0.0
is released, combine the information from v1.0.2.alpha.0
, v1.0.3.alpha.1
into a single v1.0.0
entry in the CHANGELOG; I would start simple though and not have a special case for pre-release handling.
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'm with @bcoe, the end goal should be combining them to a single entry eventually. Another option is to collect the changes in a Unrelease vX.Y.Z
and then name it to vX.Y.Z
once it's not a pre-release anymore. I could swear I've seen that around, although I'm too lazy now to search for it.
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.
Now that I'm rambling on I realise that this is a result of the workflow, not this change, never mind me.. Anyway for reference:
@bcoe I thought about combining the pre-release logs to a single one, but what about pre-releases containing fixes to other pre-releases. e.g. You do a pre-release of a new feature as v2.1.0-rc.0
with feat(god): can now obtain god powers
, but then fix an edge case of this new feature in the next prerelease v2.1.0-rc.1
: fix(god): fix edge case to give full god instead of demigod powers
. Both of them end up in the combined v2.1.0
changelog and it might end up with quite a lot of changes that are out of context.
standard-version -p --tag="<identifier>" | ||
``` | ||
|
||
### Dry run |
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.
Remove this for this PR?
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.
Why should documentation for new features of a PR not be included?
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.
The code for this is not in this PR yet
I wonder if we should let |
There is also a |
Really, after 4 days you come up |
What do you mean? I'm just saying if |
} | ||
} else { | ||
newVersion = semver.inc(newVersion, 'prerelease', argv.tag) | ||
console.log('normal: ' + newVersion) |
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.
let's drop this log line.
@stvnwrgs this is awesome work, would love to work with you to get it merged; I've been balancing |
This feature would be awesome. @stvnwrgs do you have interest in continuing work on this, or do you prefer someone else continue if they have time? I intend to review this more thoroughly as soon as I have a slot of time open. |
@AntJanus you are more than welcome to pick up the work 😄 open source projects are about community 😃 |
@AntJanus I'm out. Feel free! |
closing in favor of #129 which looks almost ready to land. |
New argument
-p
allows you to create prereleases. You can also define a prerelease identifier. via--pre-id="alpha"
(beta is default).