Home

Awesome

ember-cli-release

Build Status NPM Version Ember Observer Score

Deprecated: ember-cli-release is deprecated. We recommend using release-it instead. If you would like to automate changelog generation as well, you might want to consider rwjblue's setup script. The script automates the setup of release-it with lerna-changelog integration.

Ember CLI addon that defines a release command for bumping the version of your app or addon. It's a streamlined alternative to the npm version command, with a number of additional advantages:

Introduction to ember-cli-release at Global Ember Meetup

Installation

$ ember install ember-cli-release

This will also generate the config file config/release.js which can be used to provide default options (see below).

Usage

This addon revolves around git tags, and so relies heavily on shelling out to run git commands (unlike the wonderful git-repo-info).

When invoked with no options:

$ ember release

It will:

  1. Assume that the project uses the SemVer versioning scheme
  2. Find the latest tag that is SemVer compliant and increment its PATCH version
  3. Replace the version property of package.json and bower.json with the new version
  4. Commit all changes to the working tree
  5. Create a lightweight git tag with the new version
  6. Push the branch and the new tag to origin

See the examples section for more ways to use the command.

Options

Options can be specified on the command line or in config/release.js unless marked with an asterisk (*). Options specified on the command line always take precedence over options in the config file. Run ember help to see CLI aliases.

Hooks

A set of lifecycle hooks exists as a means to inject additional behavior into the release process. Lifecycle hooks can be specified in config/release.js. All hooks can return a thenable that will be resolved before continuing the release process. Throwing from a hook or rejecting a promise returned by a hook will halt the release process and print the error.

Hooks are passed two arguments:

There are three lifecycle hooks available:

Custom Tagging Strategy

If your app does not use SemVer or date-based tags, you may specify a custom method for generating the next tag by making the strategy property a function in config/release.js. The function takes three arguments: the project instance, an array of existing git tags, and an options hash with all option values. It must return a non-empty string specifying the next tag, or a promise that resolves with the tag name. For example:

// config/release.js
module.exports = {
  // Emulate Subversion-style build numbers
  strategy: function(project, tags, options) {
    var builds = tags
      .map(function(tag) { return +tag; })
      .filter(function(build) { return !isNaN(build); })
      .sort()
      .reverse();

    return builds[0] + 1;
  }
};

Alternatively, if the custom strategy requires additional CLI options, an object can be specified with availableOptions, getLatestTag, and getNextTag properties:

// config/release.js
module.exports = {
  strategy: {
    availableOptions: [
      {
        name: 'channel',
        type: String,
        default: 'stable',
        description: "the release's channel"
      },
    ],

    getLatestTag: function(project, tags, options) {
      // Find the latest tag in the `tags` array
      var latest = '...';

      return latest;
    },

    getNextTag: function(project, tags, options) {
      // Generate an identifier
      var next = '...';

      // Prepend the specified channel
      return options.channel + '-' + next;
    }
  }
};

Workflow

These are the steps that take place when running the release command:

  1. Abort if HEAD is already at a tag
  2. Abort if publish option is true and no NPM user is logged in or strategy is not 'semver'
  3. Calculate new version
  4. Use tag option if present
  5. Invoke custom tagging strategy if specified
  6. Otherwise, generate new version using strategy option (default: 'semver') - SemVer
    1. Look for latest tag using node-semver ordering
    2. Increment based on major, minor, or patch (default: patch) - Date
    3. Create tag name based on current date and format option (default: YYYY.MM.DD)
    4. Look for existing tag of same name, append .X where X is an incrementing integer
  7. Print new version name
  8. Invoke the init hook
  9. If working tree is dirty, prompt user that their changes will be included in release commit
  10. Replace version property of files specified by the manifest option (default: package.json/bower.json)
  11. Invoke the beforeCommit hook
  12. Commit changes
  13. Skip if working tree is unmodified
  14. Stage all changes and commit with message option as the commit message
  15. Create tag
  16. Prompt to continue with new tag name
  17. Tag the latest commit with new version using the annotation option if specified
  18. Push to remote
  19. Skip if local option is true (default: false)
  20. Push current branch and tags to remote specified by remote option
  21. Invoke the afterPush hook
  22. Publish package to NPM using current credentials if publish option is true (default: false)
  23. Invoke the afterPublish hook

Examples

To create a new tag based on the date in east cost time with a custom format:

> ember release --strategy=date --format="YYYY-MM-DD" --timezone="America/New_York"

Or to create a specific tag (no versioning strategy) with annotation, locally only:

> ember release --local --tag="what_am_i_doing" --annotation="First version wooooo!"

To create a series of SemVer prereleases, use the --premajor (or --preminor) option followed by any number of --prereleases, and finally --major (or --minor):

# v1.3.2
> ember release --premajor alpha
# v2.0.0-alpha.0
> ember release --prerelease
# v2.0.0-alpha.1
> ember release --prerelease beta
# v2.0.0-beta.0
> ember release --prerelease
# v2.0.0-beta.1
> ember release --major
# v2.0.0

Contributing

Pull requests welcome, but they must be fully tested (and pass all existing tests) to be considered. Discussion issues also welcome.

Running Tests

$ npm test