Fixes issue 42 and 94.

[schechter]

This fixes the issue where bump:git was not working when there were multiple files being bumped.
It also bumps the version of semver to allow for

• premajor
• preminor
• prepatch
• prerelease

Also adds bump:release to drop the pre-release portion of a version number.
e.g. from version 1.0.1-rc2 bump:release bumps the version from the prerelease version to 1.0.1.

[eddiemonge]

Bumping to the next increment should bump a prerelease to a full release so bump:release isn't needed.

[eddiemonge]

this is done automatically

[schechter]

@eddiemonge, re the need for bump:release, True, but it seems strange to me that from 1.0.0-rc.0 bump:major, bump:minor, and bump:patch all result in 1.0.0. I'll remove it if you like, but it seemed to me to be confusing, and not necessarily what someone would think they were going to do by bumping a version.

[eddiemonge]

The prerelease should be for the release that is before the dash, so:

• 1.0.0-rc.0 is a prerelease for 1.0.0
• 1.0.1-rc.0 is a prerelease for 1.0.1

Going from 1.0.0-rc.0 to 1.0.1 or 1.1.0 or 2.0.0 seems weird since those aren't what the prerelease was for.

[schechter]

@eddiemonge I think I've addressed all of the issues you brought up and fixed the REGEXP problem. Is there anything else you'd like done?

[eddiemonge]

Commits should be squashed down to one and use the contributing guidelines for the title and message. Can you also make sure that you have incorporated everything from https://github.com/vojtajina/grunt-bump/pull/102/files ? thanks!

[schechter]

Should be all set. I added to the readme for the changes, not sure if you wanted that in a separate commit let me know if you want it separated out?
re: 102, the only difference is that I made it an option, not a command line argument. (Users can have that set up in the grunt file of their project to set the option through a command line arg.)

[eddiemonge]

Im not sure prereleaseName should be set to rc by default. I think not setting it to anything would be better so the version gets 1.0.1-1. The dash signifies a prerelease so have a dash and a name is superfluous.

[eddiemonge]

these examples are a little confusing. why go from prepatch to prerelease?

[schechter]

re: examples/ expected behavior of prerelease
bump:prerelease is how you bump the prerelease version.
From a released version (1.0.0) you choose

• prepatch -> 1.0.1-rc.0 prerelease -> 1.0.1-rc.1
• preminor -> 1.1.0-rc.0 prerelease -> 1.1.0-rc.1
• premajor -> 2.0.0-rc.0 prerelease -> 2.0.0-rc.1

The way it is now (and in the readme) is incorrect.

• Current behavior. v1.0.0 bump:prerelease -> v1.0.0-1
  1.0.0-1 should be the prerelease for 1.0.0 so this should not be the expected behavior.

re: the defaulted prreleaeName.
There needs to be something other than an empty string as the prereleaseName otherwise the the versions are not bumped properly. They behave more like he existing functionality of prerelease which is incorrect.

[schechter]

From Semver 2.0.0:

A pre-release ... Identifiers MUST NOT be empty. ... Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

[eddiemonge]

You missed:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version

Meaning everything after the hyphen is the identifier. To have multiple identifiers, you separate them with dots.

As for the current current behavior of going from 1.0.0 to 1.0.0-1 as the next prerelease, that is a bug that existed in semver which has since been fixed. Purely upgrading semver with no other changes would make it go from 1.0.0 to 1.0.1-0.

[schechter]

I see:
With prereleaseName set to null (now the default) the behavior is what I think you expect.
1.0.0 bump:prerelease to 10.1-0
1.0.1-0 bump to 1.0.1
1.0.1-0 bump:prerelease to 1.0.2-0
The last one seems strange to me but is what semver is doing, maybe why you were asking why one would bump:prerelease from a prerelease version?)

Now defaulted to null readme updated to reflect changes.

[eddiemonge]

I'd expect that last one to go:

1.0.1-0 bump:prerelease to 1.0.1-1

But maybe that would be bump:prepatch. Otherwise, how do you increment a prerelease?

[schechter]

Agreed. After making some more changes to the REGEXP, it is now working as expected for prereleases both with and without a prerelease identifier.
without identifier:

• 1.0.1 bump:prerelease to 1.0.1-0
• 1.0.1-0 bump:prerelease to 1.0.1-1

with identifier:

• 1.0.1 bump:prerelease to 1.0.1-rc.0
• 1.0.1-rc.0 bump:prerelease to 1.0.1-rc.1

If you had previously used bump:git and are now at a version like 1.0.0-12-g10rwy where 12 is the number of commits from the tag 1.0.0

• without prerelease identifier 1.0.0-13
• with prerelease identifier 1.0.0-rc.0

[eddiemonge]

Hmm that last git part is interesting. I wonder if there is a way to fix that, or if its something that can be ignored but with a note in the readme.

edit nevermind I see you already added the note. However, the readme needs to be updated. The default prereleaseName is null so not passing one in shouldn't add the rc part. Also, all the new options are a bit confusing in the order presented.

I'm also a bit hesitant about changing the regex. I'd actually prefer there not to be a regex. I want to say semver will the do that for us but that might be an additional change that needs to happen independent of this commit

[schechter]

Not sure what you mean by ignored? I would suggest advising against bumping from a git version to a prerelease version (without a prerelaseName?)
I think the issue with bump:git to bump:prerelease with no prereleaseName should be opened as a new issue for 2 reasons. 1 bump:git is currently broken and this pull request fixes it. 2 I'm not sure this is a use case, one should be bumping to a prerelease version from a version, not a 'git version'

(What would you expect when bumping from a 'git version' to a prerelease version?)

Thoughts?

Update

• I've Updated the readme re: defaulted prerelease set to null.
• Not sure what you mean about the all the new options? The only new option is prereleaseName Are you referring to the Usage Examples section? I think I've cleaned that up a bit, but if some if it's still confusing please point out where.

Re: the RexExp would issue 119 be part of the solution to this. I'd agree that removing the regexp all together would be part of another commit/issue. (though while the functionality of bump:git is still an option I'm not sure the RegExp could be removed, probably could be simplified if issue #119 was addressed?)

[schechter]

Are there any further changes you would like to see before you're ready to accept this Pull Request?

[eddiemonge]

holy smokes batman, that is one scary regex

[schechter]

If you get rid of all the escapes (that are there so we can add a variable) it's much less scary looking. I tried to write a couple of tests, but am unfamiliar with testing node modules.
I could just copy the regex over to a test for now (though not a great strategy). If you have any suggestions on how to add tests for the regex I'd be happy to flush them out.
I have tested this quite a bit manually. Let me know if there's anything I can do to help out.

[eddiemonge]

didnt notice this before, but shouldn't the regex replace:

(-'+opts.prereleaseName+'\\\.\\\d+)?

with something that won't translate to: (-null\\\.\\\d+)? like:

(-'+ (opts.prereleaseName || '') +'\\\.\\\d+)?

[eddiemonge]

@schechter ^^

[schechter]

I don't think so.
When there is a prereleaseName the format is 1.0.0-.0
Without a name the format is different, there is not just, just the dash so 1.0.0-0 so the name || '' would not match.

[eddiemonge]

I am scared of this pr. Let me do a bit of testing to make sure it works as expected.

[eddiemonge]

This part got left off so bump:git isn't working. #129 Working on fixing it.

[schechter]

How is it not working? bump:git is working for me. I believe that part is what broke bump:git on multiple files.

What is is doing that is unexpected?

bump:git will set the version to the result of git describe if it was parsedVersion i.e. 1.0.0 + gitVerion 1.0.0-12-gre432 the version one the second file became 1.0.0-1.0.0-12-gre432

[eddiemonge]

The parsedVersion was being left off. gitVersion was being returned to version.

I fixed it in a2e06c1

[schechter]

Yes, that's correct. bump:git is now broken.
If I am at version 0.2.6 bump git results in a version 0.2.7-0.2.5-261-g300e.0
With v0.2.0 from 0.2.6 (where the repo is tagged 0.2.6) bump git resulted in a version 0.2.6-12-ert321

a2e06c1 broke bump:git again. It is not behaving as it did prior to it bring broken by 3679aecf8c

As the comment on that commit states,

If tags are named using semver versions, git describe should automatically
use the latest version as a prefix before the short sha1.

bump:git is now bumping the patch version and not behaving as documented in the README.

[eddiemonge]

This is correct behavior:

If I am at version 0.2.6 bump git results in a version 0.2.7-0.2.5-261-g300e.0

Can you show the commands and versions that you think are broken now?

[schechter]

I sorry I though the intended functionality was to make it work as it is in the README and as it was with the version I was using before. If that is the intended behavior the only thing that needs to be updated it the README. And some additional instructions. If optscreateTag is True (as is defaulted) this can not be used twice in a row. We had been using v.0.0.11 because bump:git was still working on multiple files I and made it continue to function as it did then without realizing it had changed.

Here's what happens now.
I'm on version 0.2.6 which also means the repo is tagged as 0.2.6
bump:git to 0.2.7-0.2.5-261-g300e.0
In my json files I now have a new version, 0.2.7-0.2.5-261-g300e.0 which you expect, but I also have a new tag, 0.2.7-0.2.5-261-g300e.0.
So lets use bump:git again. One might expect it to get to 0.2.7-0.2.5-261-g300e.1 but instead, since you now have a tag 0.2.7-0.2.5-261-g300e.0.
bump:git again 0.2.7-0.2.7-0.2.5-261-g300e.0
bump:git again. 0.2.70.2.7-0.2.7-0.2.5-261-g300e.0
bump:git again. 0.2.7-0.2.70.2.7-0.2.7-0.2.5-261-g300e.0

This is similar to the behavior that broke bump:git on more than one file.
I don't understand what the utility of bump:git (as you expected it, not as it is now) bump:git as it was working in v.0.0.11 was useful. Would you consider a PR that reinstated that functionality perhaps bump:gitDescribe That would set the version to the results of git describe. <current semantic version>-<git commits since that tag>-<sha>

Essentially when using bump:git behaves like bump:prerelease where git describe is the prereleaseName (but only once)?
If that is correct when using bump:git it should also set opts.createTag to false.
Something like

// GET VERSION FROM GIT
runIf(opts.bumpVersion && versionType === 'git' || versionType === 'gitPrerelease' , function() {
  exec('git describe ' + opts.gitDescribeOptions, function(err, stdout) {
    if (err) {
      grunt.fatal('Can not get a version number using `git describe`');
    }
    gitVersion = stdout.trim();
    opts.prereleaseName = gitVersion;
    versionType = 'prerelease';
    next();
  });
});

And

// BUMP ALL FILES
var version = null;
var content = grunt.file.read(file).replace(
  VERSION_REGEXP,
  function(match, prefix, parsedVersion, namedPre, noNamePre, suffix) {
     version = setVersion || semver.inc(parsedVersion, versionType, opts.prereleaseName);
    return prefix + version + suffix;
  }
);

This seems much cleaner (though does not fix the problem encountered when using it more than once in a row!)

• Should there be a bump:gitprerelease to go from 0.2.7-0.2.5-261-g300e.0 to 0.2.7-0.2.5-261-g300e.1? I'm not sure if this is possible as with each commit the git describe portion changes (both the sha and the # of commits since the previous tag) so, as far as semver is concerned each bump would be with a new prerelease identifier.

[eddiemonge]

I used the prerelease name as the easiest solution. The .0 appended on is pretty useless so maybe it could be stripped off.

bump:git again 0.2.7-0.2.7-0.2.5-261-g300e.0
bump:git again. 0.2.70.2.7-0.2.7-0.2.5-261-g300e.0
bump:git again. 0.2.7-0.2.70.2.7-0.2.7-0.2.5-261-g300e.0

should not be happening. on my testing I get

0.2.6
bump:git 0.2.7-g300e.0
bump:git again 0.2.7-g300e.0
bump:git again. 0.2.7-g300e.0

so im not sure why yours is different. You have some interesting git shas getting in there though.

Im mixed about the createTag because you can push prerelease tags to npm and they wont show up in the official list but do get pushed if you add the flag to get prerelease versions.

Running bump:git multiple times without commiting any changes between should basically do nothing since nothing has changed.

[schechter]

Seems top be a difference in your git describe options? Though I'm not entirely sure. I do know bump:git is broken for us on this version and on 0.2.0 was behaving as (I expected and as) the README indicated.

Would you be against a PR that added a bump:gitDescribe option I mentioned? That (setting the version to the output of git describe) which would reinstate functionality that existed in v.0.0.11(even though I now see you thought it was a bug, we used it as a feature)

Additionally the code I posted above does seem a lot cleaner way to do what you've got now, but probably no need for a refactor PR?

README needs to be updated to indicate that bump:git is actually intended to bump the patch version.

[eddiemonge]

I think any bump should bump the version to at least the next patch release. Yeah the README should be updated to indicate that. You could always use the setVersion option and pass in a git describe block.

Can you explain what your use case is for the "broken" way? I'm not quite grasping what you were doing.

[schechter]

Sure:
We've been using bump:git during development. When working on a feature branch of an angular app or a dependency that we have brunt-bump in and I want to test something, or use what I'm working on in another app. I'm not ready to bump the version but want to be able to point to that code, the old functionality of grunt:bump was working well for us. I guess we could use setVersion but, grunt-bump used to do this for us. Maybe it could be an option, like bump:setGitDescribe?

re: the existing bump:git I'm not sure what's happening or why you're not getting the same results. Reading the code, what I'm experiencing makes sense. I don't know how you're not experiencing the same behavior.

In your example above on the 1st bump:git the it should be tagged 0.2.7-g300e.0
On the 2nd bump:git it should take the parsedVersion 0.2.7-g300e, and use the tag as the prereleaseName and add a .0 to the end resulting in 0.2.7-g300e-0.2.7-g300e.0.
Now that the tag is 0.2.7-g300e-0.2.7-g300e.0 that is what will be used on the next bump:git. In your example above something its wrong...

0.2.6
bump:git 0.2.7-g300e.0
bump:git again 0.2.7-g300e.0
bump:git again. 0.2.7-g300e.0

That would only make sense is the git describe portion was just g300e and even then that only makes sense on the 1st commit. You used bump:git to get to 0.2.7-g300e.0 so the sha should be different on subsequent commits. You can't make 3 commits as you show above and still have the same sha? If you were using bump-only:git this would make more sense, but still, only if your git describe is only giving you the g300e.

I'd be happy to update the README but first I'd like to understand what's happening with bump:git. I would otherwise be writing documentation for behavior I am unable to replicate. I still maintain it is broken on the current version (now that I know what it's intended behavior is). I do not get the results you are showing above and don't see how, reading the code, that's what you're getting.

[eddiemonge]

https://github.com/vojtajina/grunt-bump/blob/master/tasks/bump.js#L120 takes the parsed version: 0.2.7-g300e.0, runs it through semver and determines that the base version is 0.2.7 with some prerelease identifier. It next looks at the version type https://github.com/vojtajina/grunt-bump/blob/master/tasks/bump.js#L119 and sees that it wants a prerelease. It knows that it is already a prerelease so it adds the new prerelease identifier onto the base version. Maybe you are somehow using an older version of semver?

Sorry, in the examples above I was using bump-only:git. Without the -only part then yes the sha1 (and version) should change between bumps since there are new commits. Although with type set to git then I don't think a commit/tag should happen.

[schechter]

What do you get for git describe? Unless your git describe is somehow only the sha then your results are not consistent with what should be happening.
As you say, 0.2.7 would be the base version but your prereleaseName should be the result from git describe. If git describe is 0.2.7-12-g300e Which is the formatting that I get for git describe, the version created would be 0.2.7-0.2.7-12-g300e.0 and that would also be the new tag (and thus the new prereleaseName for the next bump. This is how it keep extending the version each time.

In your example, somehow your prerease identifier (result from git describe) is only the sha and not the other parts of git decsribe which for me is<existing tag>-<commits since tag>-<short sha>

[eddiemonge]

Ok I was sort of wrong and sort of right

git describe --tags --always --abbrev=1 --dirty=-d
----------------------------
v0.3.0

 ~/Sites/OSS/grunt-bump ⮀ GIT ⭠ master ● ⮀
grunt bump-only:git
-----------------------------
Running "bump-only:git" (bump-only) task

Running "bump:git:bump-only" (bump) task
>> Version bumped to 0.3.1-v0.3.0.0 (in package.json)

Done, without errors.

 ~/Sites/OSS/grunt-bump ⮀ GIT ⭠ master ● ⮀
grunt bump-only:git
-----------------------------
Running "bump-only:git" (bump-only) task

Running "bump:git:bump-only" (bump) task
>> Version bumped to 0.3.2-v0.3.0-d.0 (in package.json)

Done, without errors.

 ~/Sites/OSS/grunt-bump ⮀ GIT ⭠ master ● ⮀
grunt bump-only:git
-----------------------------
Running "bump-only:git" (bump-only) task

Running "bump:git:bump-only" (bump) task
>> Version bumped to 0.3.3-v0.3.0-d.0 (in package.json)

Done, without errors.

 ~/Sites/OSS/grunt-bump ⮀ GIT ⭠ master ● ⮀
grunt bump-only:git
-----------------------------
Running "bump-only:git" (bump-only) task

Running "bump:git:bump-only" (bump) task
>> Version bumped to 0.3.4-v0.3.0-d.0 (in package.json)

Done, without errors.

[schechter]

Yea that looks closer to what I would expect and am experiencing. If you committed instead of bump-only the tag would become 0.3.1-v0.3.0.0 after the 1st one and that's how I end up with increasing longer versions.
The Version 0.3.2 (with it's patch version bumped from 0.3.1) gets the prerelease identifier of your tag 0.3.1-v0.3.0.0 plus the .0 which should result in. 0.3.2-0.3.1-v0.3.0.0.0

Perhaps the better would to be use git rev-parse --short HEAD as the prereleaseName. This would solve the problem of the tag growing with each use of bump:git (with a commit). If git rev-parse --short HEAD was used it would always just be the <version>-<short sha>. We could then always strip off the trailing .0 as there is no need for the .0 when using this type of bumping

Thoughts?

[eddiemonge]

That sounds good.