search

EOSIO / demux-js-eos

Demux-js Action Reader implementations for EOSIO blockchains
MIT License
38 stars 17 forks source link

Automate publishing of @latest from master when creating a GitHub release #34

Closed flux627 closed 5 years ago

flux627 commented 5 years ago

How this currently works:

  1. Increment the package.json as part of a pull request to develop (possibly along with other changes)
  2. Merge develop into master (PR named something like "Release version ___")
  3. Once it's merged, go to the "Releases" tab in GitHub, and create a new release on master. The tag must be the same as the version in package.json (without a v).
  4. Once the GitHub release is created, it will simultaneously create the tag. The tag will trigger travis to publish to NPM.

The only problem as of right now is that minor releases might not need release notes. In that case, after step 2, you must tag the head of master locally, and then push it up. This will trigger the publish on Travis. If we end up not liking this, here are some ideas for how we can improve it:

  1. Have Travis auto-tag minor version updates, which will trigger itself to publish. This might be tricky to get right
  2. Have an NPM script called "release-minor" that is invoked locally that tags the head of master with the current NPM version (checking to make sure that it aligns with master's package.json)
  3. We write a GitHub release for every update, minor or otherwise.
flux627 commented 5 years ago

Another hacky way would be to create a GitHub release, then delete the release. This keeps the tag, so it's effectively the same as creating the tag local and pushing it up. This is unfortunately the only way to create a tag from GitHub (without a release).

chris-allnutt commented 5 years ago

I don't see a problem with option 3, even a minor revision is a release. The question comes in is if we believe the minor version has a change significant enough to benefit developers. If a minor release fixes a bug (e.g. retries) then as a dev following releases I'd want to know that was in. If a minor release updates documentation or does some code refactoring then there's little to no benefit in releasing.

chris-allnutt commented 5 years ago

I don't feel confident approving this but I added @masaka3620 and @jeffreyssmith2nd as requested reviewers.

masaka3620 commented 5 years ago

Another option could be to have the release update the package.json with the new version. We currently do that with eosjs. That might avoid some of the problems you mentioned and also lets you create draft releases with early notes if you want to go that route.

flux627 commented 5 years ago

@masaka3620 I thought about that, and chose this path because it puts the version upgrade in the peer-reviewed PR process. This way, any version that's released was signed off by at least one other person. If you attempt to release a version that's not the same as the package.json, it fails.