We often bump the version of a gem (e.g. everypolitician-ruby or everypolitician-popolo but forget to (or don't have permission to) release the resulting version to rubygems.org. This can lead to confusion when trying to update a version of a gem only to find out that it hasn't actually been released.
Whenever a tagged commit is pushed and tested on Travis, it should result in a new version of the library being released to rubygems.org.
Not Required
It would be nice to try out Travis' support for prereleases which will release a "pre" version of the gem after each build, but that's not needed for the initial version.
It may also be nice to have a script run on Travis that notices that version.rb has been changed in the commit that's being tested and then automatically tag that commit so that a release will be created, but that's not needed for the first version.
Problem
We often bump the version of a gem (e.g.
everypolitician-ruby
oreverypolitician-popolo
but forget to (or don't have permission to) release the resulting version to rubygems.org. This can lead to confusion when trying to update a version of a gem only to find out that it hasn't actually been released.Proposed Solution
Use Travis' RubyGems Deployment to automatically publish tagged commits to RubyGems.org.
Acceptance Criteria
Whenever a tagged commit is pushed and tested on Travis, it should result in a new version of the library being released to rubygems.org.
Not Required
It would be nice to try out Travis' support for prereleases which will release a "pre" version of the gem after each build, but that's not needed for the initial version.
It may also be nice to have a script run on Travis that notices that
version.rb
has been changed in the commit that's being tested and then automatically tag that commit so that a release will be created, but that's not needed for the first version.Prerequisites
None.
Related Issues
None.
Due Date
ASAP!
Design?
No.
Text?
No.
Bloggable?
?