ericclemmons / github-semantic-version

Automated semantic version releases powered by Github Issues.
MIT License
21 stars 8 forks source link

Initial Release #1

Closed ericclemmons closed 8 years ago

ericclemmons commented 8 years ago
  "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}\""
  },
ericclemmons commented 8 years ago

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 commented 8 years ago

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

ericclemmons commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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:

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)