@RST-J @hoxworth This might make releasing a lot easier

What do the GemHelper tasks do? Will they perform the test task and increase the version number and then release? If so, cool.
Would it be possible to have a task that uses more than one ruby version (assuming everyone uses rvm) and have this task be executed prior to releases? I think it would be good to have the lowest and latest supported version of MRI and the not MRI versions tested.

It does everything except run tests. We could easily add tests as a dependency, but not for multiple versions of Ruby. Personally I think even that is unnecessary. I think we have to trust that releases aren't rushed and people check Travis first.=

I thought of this because Travis is not rerun when things get merged, as the incident yesterday showed.
But if we always have a single PR for bumping the version as last merge, this should still be covered.
So 👍

I thought Travis usually does run a build after a merge, because it's just another commit?

I know they had a large backlog yesterday (there was a disclaimer saying their linux builds were backed up) so it might have been a one-off?=

I don't know. I meant other PRs that are open and have been built before. If they are green and then another PR is merged, other pending PRs are not retested or are they?

Ah no - my understanding is that a build is triggered whenever there is a new commit. For unrelated branches, there's no change, so travis doesn't build. There is some discussion of adding this feature: travis-ci/travis-ci#1620

The process I've always followed was:

1. Run tests!
2. Update version in VERSION.yml
3. Build a new gem: gem build json-schema.gemspec
4. Tag the release: git tag -a <version>
5. Release the gem: gem push json-schema-<version>.gem
6. Push to github: git push --tags

Seems as if the only thing that bundler adds is consolidating step 3 & 4 above, correct (and probably not using an annotated tag in the process)? Reducing steps is definitely a good thing... but it wold be great if there were a single release target that would update VERSION.yml, build the gem, tag the release, and publish the gem.

Anyway, just a comment. I'm okay with merging this to reduce at least one step.

I think the bundler tasks do 3, 4, 5 and 6 (can't remember if it pushes the tags back up, but I have a feeling that it does)

(That's the release task I'm thinking of)

@iainbeeston's right, bundler's rake release does everything in steps 3-6. The release process after this would just be:

1. Check travis results for master (and probably run locally for sanity)
2. Update VERSION.yml
3. rake release

👍

Ok, two observations:

1. The bundler release task tags as "v2.5.0" not "2.5.0" (older releases had no "v" at the start)
2. It doesn't push tags back up to github, which is surprising because the output sounds like it does:

json-schema 2.5.0 built to pkg/json-schema-2.5.0.gem.
Tagged v2.5.0.
Pushed git commits and tags.
Pushed json-schema 2.5.0 to rubygems.org.

Ah... It pushes tags to origin - which is my personal fork of the repo...