-
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
support releasing a custom version, including pre-releases #129
Conversation
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 this is related to #83 (Preid PR) #84 (releaseAs issue) and #122 (Preid Issue).
Thanks for contributing. A few concerns I have:
tag-id
should IMO be the--prerelease
[-p
] that was discussed in Feature/add preid param for semver #122. This option should convert the bump to apre(major|minor|patch)
as in Feature/add preid param for semver #83. Otherwise you are forced to manually find out what version you want toprerelease
and use it with themanual|release-as
option, kind of going against the idea ofstandard-version
. To set the prerelease tag you would-p alpha
.manual|release-as
would only need to acceptmajor|minor|patch
as input, since the-p
flag should set it as aprerelease
when nomanual|release-as
is given and otherwise-p
would set it aspremajor|preminor|prepatch
.
What this would entail is:
- Either getting the recommended bump from
conventional-recommended-bump
or using the(major|minor|patch)
from(manual|release-as)
flag. - Prefixing the bump with
pre
ifprerelase
flag is used, and supplying either the given or default prerelease tag tosemver.inc
.
If the above doesn't resolve prereleases with breaking changes (e.g. patch
prerelease into (major|minor)
prerelease) correctly, it'll need a modified version of this function in #83.
@@ -3,7 +3,25 @@ | |||
root = true | |||
|
|||
[*] |
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.
Could you create a separate PR for modifying the .editorconfig
? Thanks 😄
@@ -4,6 +4,21 @@ var defaults = require('./defaults') | |||
|
|||
var argv = require('yargs') | |||
.usage('Usage: $0 [options]') | |||
.option('manual', { |
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.
release-as
[-r
] would be a good name IMO (@stevemao opinion?).
choices: ['major', 'premajor', 'minor', 'preminor', 'patch', 'prepatch', 'prerelease'], | ||
global: true | ||
}) | ||
.option('tag-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.
prerelease
would be my preference, see the summary comment on why.
version[type] += 1 | ||
|
||
var content = fs.readFileSync('CHANGELOG.md', 'utf-8') | ||
content.should.match(new RegExp(version.major + '.' + version.minor + '.' + version.patch)) |
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 dots in the regex should be escaped. E.g. version.major + '\.' + version.minor + '\.' + version.patch
.
version[type.slice(3)] += 1 | ||
|
||
var content = fs.readFileSync('CHANGELOG.md', 'utf-8') | ||
content.should.match(new RegExp(version.major + '.' + version.minor + '.' + version.patch + '-' + type + '.0')) |
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 dots in the regex should be escaped. E.g. version.major + '\.' + version.minor + '\.' + version.patch
.
}) | ||
}) | ||
|
||
it('creates a prerelease with a new minor version after two prerelease patches', function () { |
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.
This works correctly when specifying the preminor
manually, but how about prerelease
? Would that bump the patch
version? That would be very counterintuitive. This might not be worth fixing before deciding on the points in my summary though.
@Tapppi all your comment can be worked out except this:
That involves some problems:
so, the default value for |
@@ -2,12 +2,12 @@ | |||
"name": "standard-version", | |||
"version": "3.0.0", | |||
"description": "replacement for `npm version` with automatic CHANGELOG generation", | |||
"bin": "cli.js", | |||
"bin": "bin/standard-version.js", |
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 naming needs to be changed. cli
should be the bin
. So you'd need to rename the files to whatever you think makes more sense :)
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.
but 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.
cli by convention should be the bin
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.
got it. what if i rename bin/standard-version.js
to bin/cli.js
and cli.js
to command.js
?
06d413c
to
a111a4b
Compare
@stevemao do you have time to review this again? |
describe('release-types', function () { | ||
var regularTypes = ['major', 'minor', 'patch'] | ||
|
||
regularTypes.forEach(function (type) { |
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 wouldn't auto generate tests like this. I'd keep it DAMP.
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.
But in this case we dont add a bunch of fixtures to avoid duplication. I think its readability is acceptable, just opinion. If you insist, i can expand it. I would be much longer.
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'd probably just test one for each assertion. EG: say test 'major'
for "creates a major release" and 'patch'
for "creates a pre-patch release". Not a big deal :)
it looks awesome In general. Thanks, @e-cloud. |
this is for better modularity, and, for more convenient test. before, you can't breakpoint-debug the source mostly when testing for the usage of shelljs. now, some of the test cases can be done potentially with this commit
Here uses promise for some of the test cases, works nicely, thanks bluebird.
I just add docs in Readme.md. Anybody could review this? |
@e-cloud really appreciate this work; sorry for the slow turn around on this repo lately, going to work on seeing this over the finish line 👍 |
@stevemao @Tapppi sorry that I've been so AWOL the past couple months -- haven't been able to carve as much OSS time out as I would like to. Please feel free to land any pull requests that meet your guidelines; I've added you both to the npm module so that I don't block you on publishing, and I very much trust your instincts with regards to features. |
@bcoe @e-cloud sorry to bump this, but this is fricking awesome, I just released my first pre-release of an internal company package automagically from our CI server after versioning with |
@Tapppi if you're comfortable signing off on everything, I say release it! my two cents:
want to cut a release @Tapppi you should have access to the module on npm now too. |
@bcoe I think both of those points are crucial but big enough to warrant thinking a bit more about them instead of trying to rush them in. I'll give releasing |
major changes
--release-as
to release a custom version like npm version--prerelease
to name a pre-release or tag a release as prerelease without option value, it can be used with--release-as
this PR is similar to #83 , but this provide more version-control.
PS: some of the test code are borrowed from tests for #83
PPS: I'm bad at naming the option. Feel free to suggest new names for those options.