Initial Release

[ericclemmons]

• [x] Primarily powered by github_changelog_generator
• [x] Wraps several commands specified by the User via this Lib (here's the latest functioning version).

  "scripts": {
    // User
    "build": "babel src -d dist",

    // Lib
    "changelog": "npm run changelog:generate && npm run changelog:add",
    "changelog:add": "git add CHANGELOG.md",
    "changelog:generate": "github_changelog_generator --future-release $npm_package_version",

    // User
    "coverage": "npm test && nyc report --reporter=text-lcov | coveralls",

    // Lib
    "preversion": "npm run build",
    "postversion": "npm run version:amend && npm run publish",
    "publish": "git push orign master --tags",

    // User
    "test": "NODE_ENV=test nyc mocha",

    // Lib
    "version": "npm run changelog",
    "version:amend": "git commit --amend -m \"Release v${npm_package_version}\""
  },

• [x] Only does a release when there's been a new milestone completed that has not been published (therefore updating CHANGELOG.md).

[ericclemmons]

Here's another reference:

https://github.com/ericclemmons/reload-server-webpack-plugin/blob/ae810197c8768d9e6e970991ed0121af0e2afc4e/package.json#L10-L22

Personally, I like npm version v1.2.3 for explicitness.

[ericclemmons]

See: npm/npm#3059 where npm install inexplicably runs npm preinstall. :shrug:

[ericclemmons]

If this were to "auto-version", it'd be something like this:

1. Build passes.
2. All milestones are fetched, sorted desc, & pruned by those with no more open issues (e.g. https://api.github.com/repos/ericclemmons/reload-server-webpack-plugin/milestones?state=all&sort=completeness&direction=desc)
3. If $npm_config_package_version or whatever differs from the latest tag, then the Travis runs npm version $tag.

That's about it. In the future, this could "close" the Milestone, since it's been released.

[ericclemmons]

Also, should we force package.json files? Otherwise, it's possible for there to be a huge amount of crap unless the user is on top of it.

[comamitc]

I'm interested in contributing to this.

As to your last comment: It might not be a bad idea to make this pluggable. That way users can install their specific plugins for their respective build tools to set the new version.

The community will be responsible for building these as the need arises.

[ericclemmons]

@comamitc Interesting! Something we should discuss some more. It'll probably be a bit opinionated, as I just attempted to use https://github.com/semantic-release/semantic-release several times but didn't care for the workflow.

Regarding pluggable, I figured we'd be able to rely on:

• Projects using npm and, therefore, package.json.
• npm version for releasing a specific version.
• npm publish for publishing. Remember, this doesn't necessarily have to post to NPM! It can also deploy to Tutum, for example.

Re: files - That's too opinionated. I found from experience it's useful (for me), but primarily for open-source projects only (that get published to NPM).

Either way, I definitely want to talk through action steps and we can nail down the workflow, then the pieces missing. (And I have a pretty good idea on it all, since I've been using this workflow for several projects)