vojtajina / grunt-bump Goto Github PK

It'd be rather nice and useful if we could get the %VERSION% variable in the grunt.initConfig's scope. An example usage of it could be to include the version number in banners

There have been a lot of changes to the semver spec and to node-semver from version 1.x to 2.x. The grunt-bump task should be updated to use version 2.x of node-semver to keep up with those changes (should probably only be a matter of changing the package file).

Would be nice to have a "test run" option which would run the task without doing anything actually.

I setup everything in my repo but I'd like to test my configuration without creating an actual release.

It would log every step in the console and that way we could spot an error in the config.

Thank you for your work :)

Here's what my terminal looks like:

$ grunt bump:minor
Running "bump:minor" (bump) task
>> Version bumped to 0.3.0
>> Committed as "Release v0.3.0"
>> Tagged as "v0.3.0"
Fatal error: Can not push to upstream:
  fatal: 'upstream' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Here's an excerpt from Gruntfile.js

bump: {
    commit: true,
    commitMessage: 'Bumped version to v%VERSION%',
    commitFiles: ['package.json'],
    createTag: true,
    tagName: 'v%VERSION%',
    tagMessage: 'Version %VERSION%',
    push: true,
    pushTo: 'origin'
}

So I'm trying to push to origin, but for some reason grunt-bump thinks I'm trying to push to upstream even though my config specifically tells it that I want to push to origin.

From my gruntfile:

pkg: grunt.file.readJSON('package.json')
,bump: {
    files: ['package.json']
    ,updateConfigs: ['pkg']
}

Say that package.json starts at version "0.0.1"

I'm running: grunt bump-only:patch clean copy replace

In my replace step, I'm reading values from pkg but they still show the value before the bump:

,replace: {
    options: {
        patterns: [
            //...
            ,{
                match: 'VERSION'
                ,replacement: function(){
                    return grunt.config.data.pkg.version;
                }
            }
        ]
    }
    ,build: {
        files: [...]
    }
}

This replaces @@VERSION with "0.0.1" even though package.json shows "0.0.2" after grunt is done.

Am I not writing updateCongfigs correctly?

Hi All,

How hard would it be to revert the bump if the build fails?

The repository doesn't have a license, just thought it maybe might be useful to add one.

The commitFiles option no longer supports ['-a'].

Grunt file expand will see '-a' as not a valid path and remove it from the array.

grunt.file.expand(opts.commitFiles).join(' ')

https://github.com/vojtajina/grunt-bump/blob/master/tasks/bump.js#L146

Presently I'm using a combination of this task and grunt-release because I need the publish to npm functionality from grunt-release, and I need the updateConfigs option from grunt-bump (which grunt-release does not support).

If grunt-bump provided an option to publish to npm, I could drop the dependency on grunt-release.

Hey Vojta,

Thanks for your work on grunt-bump. I've been using it successfully for a few months now.

I had an issue come up yesterday, however, when I did a fresh clone and npm install: it failed since I'm still on Grunt 0.3, even though I have the version of grunt-bump set to ~0.0.2. It would be great, going forward, if you could tag and version releases of grunt-bump so it's not "automatically" updated. In my case, the changes ended up breaking things.

Thanks!

I would like to create a grunt task doing bump-only, changelog and bump-commit in succession.

However the following code does not work because bump-commit is asynchronous and the changelog is using the version which is not updated.

module.exports = function(grunt) {
  require('load-grunt-tasks')(grunt);

  grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
    changelog: {
      options: {
        dest: 'CHANGELOG.md'
      }
    },
    bump: {
      options: {
        commitFiles: ['package.json', 'CHANGELOG.md'],
        pushTo: 'origin'
      }
    }
  });

  grunt.registerTask('release', 'Release new version', function (type) {
    if(!type) type = 'patch';
    if (!(type === 'minor' || type === 'patch')) {
      grunt.log.writeln('Use grunt release:patch or grunt release:minor');
      return;
    }

    // The following code does not work because bump-only is async
    grunt.task.run('bump-only:' + type);
    grunt.config.set('pkg', grunt.file.readJSON('package.json'));
    var pkg = grunt.config.get('pkg');
    // Here the version is still not updated
    grunt.log.writeln('version is ' + pkg.version);
    grunt.task.run('changelog');
    grunt.task.run('bump-commit');
  });
};

Hey there, cool plugin. I had an idea though, what if running grunt bump did the following:

• update the version in package.json
• git commit -m "release [version]"
• git tag [version]
• git push --tags
• npm publish

I often forget to do one or more of those things when bumping the version. grunt-bump ftw.

Hi,

It would be nice if we could customize the regexp used to match versions.
In my use case, I also maintain the version number in my README.md file using the following markup: <sup></sup>: https://github.com/ngryman/jquery.finger.

Being able to specify this directly in the Gruntfile.js would be great.

Thanks!

registerHelpers will be depreciated in grunt 0.4.

To see how helpers will be handled in the future (using standard npm require), check out the following links:
https://github.com/gruntjs/grunt-contrib-uglify/blob/master/tasks/uglify.js#L15
https://github.com/gruntjs/grunt-contrib-uglify/blob/master/tasks/lib/min.js

I'm posting this issue to let you know that we will be publishing Grunt 0.4 on Monday, February 18th.

If your plugin is not already Grunt 0.4 compatible, would you please consider updating it? For an overview of what's changed, please see our migration guide.

If you'd like to develop against the final version of Grunt before Monday, please specify "grunt": "0.4.0rc8" as a devDependency in your project. After Monday's release, you'll be able to use "grunt": "~0.4.0" to actually publish your plugin. If you depend on any plugins from the grunt-contrib series, please see our list of release candidates for compatible versions. All of these will be updated to final status when Grunt 0.4 is published.

Also, in an effort to reduce duplication of effort and fragmentation in the developer community, could you review the grunt-contrib series of plugins to see if any of your functionality overlaps significantly with them? Grunt-contrib is community maintained with 40+ contributors—we'd love to discuss any additions you'd like to make.

Finally, we're working on a new task format that doesn't depend on Grunt: it's called node-task. Once this is complete, there will be one more conversion, and then we'll never ask you to upgrade your plugins to support our changes again. Until that happens, thanks for bearing with us!

If you have any questions about how to proceed, please respond here, or join us in #grunt on irc.freenode.net.

Thanks, we really appreciate your work!

I'd like the ability to pass in the file(s) I'd like to have bump bump, not just package.json.

We use grunt-bump for https://github.com/hoodiehq/hoodie.js.

The problem we're facing is hoodiehq/hoodie#231 (comment): the version in the build files are out of sync with the version of the actual project bumped by the grunt task.

Unless I'm not missing anything, we'd need a callback that allows us to run custom grunt tasks after the versions have been bumped, but before the changes are commited. Something like this maybe

    bump: {
      versions: {
        options: {
          files: ['package.json', 'bower.json'],
          beforeCommit: ['build']
        }
      }
    }

Hello
looking at the readme and #62, I am bit confused, because I would interpret 'bump' as 'increment the version number':
Assuming we have version 1.2.3, and grunt bump:prerelease will generate 1.2.3-0, I would rather call this a 'reverse bump' or 'bump-down', since according to semver 1.2.3 > 1.2.3-0.

A subsequent grunt bump:prerelease will then correctly bump-up 1.2.3-0 to 1.2.3-1

Following this argumentation, if we do a 'grunt bump:minor' on 1.2.3-rc.1, the result should be 1.2.3 (not 1.2.4), because 1.2.3-rc is an unstable prerelease of 1.2.3.

Ok, this may be a bit academic, and even more confusing ;-)

Background of my question: I want to establish this workflow:

1. (just released 1.2.3)
2. bump to 1.2.4-dev
3. hacking away on the next release, maybe releasing nightly builds 1.2.4-dev.1, ...
4. bump to 1.2.4 , commit and push

How would you suggest to do that with your tool (or would you suggest another workflow)?

Hi!

I am trying to install your dependencies but it doesn't work at all.

Here is what I have in the console.

(node) warning: Recursive process.nextTick detected. This will break in the next version of node. Please use setImmediate for recursive deferral.

util.js:35
  var str = String(f).replace(formatRegExp, function(x) {
                      ^
RangeError: Maximum call stack size exceeded

Config

 "grunt-bump": "0.0.14"

bump: {
  options: {
    commitMessage: 'Release v%VERSION%',
    tagName: '%VERSION%',
    push: false,
    pushTo: 'origin'
  }
}

Hello,

Just wanted to say thanks for the great work with this module, it's very helpful. I have a requirement for a project to be able to bump not only the package.json, but another XML file in the repo as well.

If I were to send you a PR attempting to make the regexp an option with the current behavior unmodified, would you consider merging? Or should I take another route?

Thanks,
Ben

After 3679aec, running $ grunt bump:git causes errors when bumping multiple files:

Running "bump:git" (bump) task
>> Version bumped to 0.4.0-0-d513-d (in package.json)
>> pkg's version updated
>> Version bumped to 0.4.0-0-0.4.0-0-d513-d (in bower.json)
Warning: Bumping multiple files with different versions!� Use --force to continue.

 Aborted due to warnings.
grunt build returned exit code 6action grunt build failed

bump.js, line 126

globalVersion = grunt.file.readJSON(opts.files[0]).version;

The grunt.initConfig bump object contains

files: [
  'app.json',
  'bower.json',
  'package.json'
]

app.json is

{
  ...
  "application": {
    ...
    "version": "1.1.0"
  },
  ...
}

The version property is not at the root of app.json and opts.files[0].version returns nothing
The quick fix is simple, simply define the files array this way

files: [
  'bower.json'
  'app.json',
  'package.json'
]

But I though it's worth mentioning it

I can see the code for committing has changed to:

exec('git commit ' + grunt.file.expand(opts.commitFiles).join(' ') + ' -m "' + commitMessage + '"', function(err, stdout, stderr) {

This used to be without the grunt.file.expand(), thus making ['-a'] work. Now it's looking for files and I can't tell it to commit all changed files.

Also a suggestion with this: I'm guessing it won't push new files. Maybe an option for git add?

Thanks!

After upgrading to 0.0.14, getting "Fatal error: Can not create the commit:" without any more explanation messages. Reverting to the previous version fixes an issue.

Hey,

with this configuration:

 grunt.config('bump', {
    release: {
      options: {
        push: false,
        commitMessage: 'source-%VERSION%',
        // commit all modified files
        commitFiles: ['-u']
      }
    }
  });

(I removed upstream for testing, because it kept pushing to it)

Assuming I have already set my package.json version manually it would be handy to call bump:sync which would just copy these values to the other targets listed in options.files.

This would be even more useful, if we had an additional options.syncFields (defaulting to ["version"]) that would allow to sync description, keywords, etc.

Hi,

It's me again, sorry for the flood. Two other enhancements here.

• Adding a tasks option would be awesome.
  A little what grunt-contrib-watch already does, grunt-bump could execute the specified tasks between bump-only and bump-commit automatically, so we can create a custom bump pipeline easily.
  In my use case, I would like to concat and minify some files again so that they include the new version number in their respective headers.
• Kind of like you did with bump:git, it would be great to have some sort of bump:custom accepting an additional param that would be appended to the current version.
  For example, let's say my project is at 0.9.0. I'm pretty satisfied, but not willing to release 1.0.0 yet. Instead I would like to create some versions between indicating that I'm soon releasing 1.0.0, for example:

0.0.9-alpha
0.0.9-beta
0.0.9-beta.1
0.0.9-rc.1
0.0.9-rc.2
1.0.0

Something like this would be cool:

#0.0.9
git bump:custom --version=beta
#0.0.9-beta

Thanks!

It seems the registerHelper function is deprecated. I refactored the code to be compatible with the current development version of Grunt.

https://github.com/tarcon/grunt-bump/commit/5d839f3ce5efb1f282add7d5dac3e9c5938c0cd3

I am relatively new to GitHub but would like to see support for lightweight tags here in grunt-bump. Please consider this idea or allow me to directly contribute. In other words, do not add the -a option for an empty tag message:

    diff --git a/tasks/bump.js b/tasks/bump.js
    index 8511d5b..206ecba 100644
    --- a/tasks/bump.js
    +++ b/tasks/bump.js
    @@ -157,8 +157,14 @@ module.exports = function(grunt) {
         runIf(opts.createTag, function() {
           var tagName = opts.tagName.replace('%VERSION%', globalVersion);
           var tagMessage = opts.tagMessage.replace('%VERSION%', globalVersion);
    -
    -      exec('git tag -a ' + tagName + ' -m "' + tagMessage + '"' , function(err, stdout, stderr) {
    +      var cmd = 'git tag ';
    +      if (!!tagMessage) {
    +        cmd += '-a ' + tagName + ' -m "' + tagMessage + '"';
    +      }
    +      else {
    +        cmd += tagName;
    +      }
    +     exec(cmd, function(err, stdout, stderr) {

Thanks for this handy task.

Hi there,

awesome task to automate releasing. There is just one thing im missing im my use case.

Let me describe my non automated workflow so far:

1. Im working on develop branch
2. I finished my work and ready to release.
3. No I do the following the on develop branch.
   • Generate Changelog
   • Bump version number
   • Merge in master branch
4. Push master branch to remote repository

What do you think about this?

I have the following config:

        bump: {
            options: {
                files: ['package.json', 'bower.json'],
                commit: true,
                commitFiles: ['-a'],
                createTag: true,
                push: false
            }
        }

If I stage some changes and then run grunt bump with 0.0.11, there will be a new commit that includes my staged changes as well as the result of the bump. If I do the same thing with 0.0.14, there will be a new commit with my staged changes, but the result of the bump won't be part of it, and will be unstaged.

Need to add tests to verify functionality. Open to suggestions on how to do this. Mostly looking for a way to mock the git calls.

Hey there.

I'm not sure if this is a bug or not, but I'm unable to automatically add unstaged / added files in the repo using the commitFiles key and flags? For some reason neither of these are working:

commitFiles: ['-a --untracked-files=all']

or

commitFiles: ['-a --u']

or, even the new git add preferred syntax:

commitFiles: ['-A']

I have the following in my Gruntfile.coffee:

    bump:
      files: ['package.json', 'bower.json']
      updateConfigs: ['pkg']
      commit: false
      createTag: false
      push: false

But the task is still committing/tagging/pushing:

Running "bump" task
>> Version bumped to 0.3.3-0
>> Committed as "Release v0.3.3-0"
>> Tagged as "v0.3.3-0"
>> Pushed to origin

In general, I'm wondering why this behaviour is the default... Git committing/tagging/etc is usually done as the very last step of a build process (if at all), while bumping the version number is often done before generating templates etc. that may make use of the new version.

Would be super handy to see what's changed without combing through individual commits

I don't understand why you have commits that are not pushed to remote

I want to bump the build version on each commit. I want bump to commit the new version file without triggering the pre-commit hook. Is that possible?

Too much tagging kills tagging :)

I am probably dreaming as this is unlikely (so please do close).

It would be fantastic to be able to bump:undo to revert a last bump. I love this utility, but frequently I see it being used by mistake. For example bumping before committing the changes.

Reproduce:

1. Assume version "0.0.1"
2. bump:build
3. bump:patch

Outcome:
version is "0.0.2-0"

Expected outcome:
version should be "0.0.2"

When running

$ grunt bump:git
>> Version bumped to 1.0.0-1-ge96c
>> Committed as "Release v1.0.0-1-ge96c"
>> Tagged as "v1.0.0-1-ge96c"
>> Pushed to origin

The version is actually set to "ge96c" and not "1.0.0-1-ge96c". This is also obvious when looking at the code:

 version = gitVersion || semver.inc(parsedVersion, versionType || 'patch');

semver.inc is only used if gitVersion is not set.

--setversion=xxxx works via command line. How can I use this via configuration? I need to grab a specific version number from another location and I would like to do that during a grunt task? I tried grunt.registerTask('bump-webcenter', 'Bump package.json version to match WebCenter Protal', function() {
grunt.task.run('bump --setversion=' + myVersion);
});
but I get task not found. Am I just doing it wrong?

Hello,
thanks for your work on grunt-bump.

I saw the following possible issue: When using the push option bump is pushing twice to the remote server which doesn´t seems necessary

exec('git push ' + opts.pushTo + ' && git push ' + opts.pushTo + ' --tags', function(err, stdout, stderr) {...

Kind regards,
Chris

I might want to only make a tag for a certain type of release. Would that be possible?

So instead of createTag: true, it might be createTag: ['major'], or createTag: ['major', 'minor'],?

Would be nice to handle bower's component.json file if available.

What do you think?

Quickly hacked something around it so far:

    grunt.registerTask('bump', 'Increment version number', function() {
      var versionType = grunt.option('type');
      function bumpVersion(version, versionType) {
        var type = {patch: 2, minor: 1, major: 0},
            parts = version.split('.'),
            idx = type[versionType || 'patch'];
        parts[idx] = parseInt(parts[idx], 10) + 1;
        while(++idx < parts.length) { parts[idx] = 0; }
        return parts.join('.');
      }
      var version;
      function updateFile(file) {
        var json = grunt.file.readJSON(file);
        version = json.version = bumpVersion(json.version, versionType || 'patch');
        grunt.file.write(file, JSON.stringify(json, null, '  '));
      }
      updateFile('package.json');
      updateFile('component.json');
      grunt.log.ok('Version bumped to ' + version);
    });

In my case, I have some meta-banner added to built files that includes the version. So my usual workflow is:

• bump versions
• grunt build
• git commit/tag/push

Looks like an easy way to support this would be to switch to a grunt multiTask & provide a way to disable bumping (thus only committing / pushing).

Would you be interested by a PR regarding this?

I'd like to be able to bump, e.g. 2.9.0 to 2.10.0-0 with a single task, e.g. grunt bump:minorprerelease.

At present this doesn't seem to be possible.

It would be nice to have an option to add a confirmation before actually running the bump tasks to prevent accidents.

Something like:

$ grunt bump
>> You are about to bump to 0.0.2, commit, tag, and push.
>> Do you wish to proceed? [y/N]: y
>>
>> Version bumped to 0.0.2
>> Committed as "Release v0.0.2"
>> Tagged as "v0.0.2"
>> Pushed to origin

If you run a task after the version has been bumped pkg.version is out of date. It can be reloaded with something like:

grunt.config.set("pkg", grunt.file.readJSON("package.json"))