Since bootstrapping a gem also inits git, I think we should create a default .gitignore file too.

It could contain the following:

*.gem
Gemfile.lock

Any other candidates to exclude?

Also, should Gemfile.lock be removed from gem-release itself? In general, Gemfile.lock files should be excluded from git for gems, but not apps, although I'm not sure how I feel about it here.

@svenfuchs - your thoughts please :)

Neat gem; I like it a lot.

Is there a way to get the current version without having to grep or sed lib/my_gem/version.rb? I'd like to have a task in a Rakefile to create a git branch with the name of the version, similar to your gem tag command, but I'm having trouble figuring out the right incantations. Alternatively, being able to get the "bumped" new version as just a plain text-string on STDOUT would let me mess with it on my own, like a stripped-down --pretend.

These are probably more enhancement requests than Issues...

Thanks for the good work! :-)

As discussed in #15, we should add a prompt to gem release (and gem bump --release) for confirmation before pushing both public and private gems.

For instance, Release version 1.0.1 of public_gem to rubygems.org? (y / n) or Release version 1.0.0 of private_gem to http://rubygems.example.com? (y / n). Skip this prompt with the --quiet / -q option.

Hi, this is probably not problem in gem release, opening anyway as maybe it will help others troubleshooting.

I've tried enabling multi-factor authentication in rubygems.org at "UI and API".
This should make gem push prompt for an OTP code:
https://guides.rubygems.org/using-mfa-in-command-line/
But I didn't use gem push directly, I used gem release which it seems failed, without prompting me for an OTP code. (Sorry, didn't save the output, laptop lost power since).

Is there any known limitation? Are executed commands connected to stdin?

Alternatively, could add an --otp flag to be passed on to gem push, requiring no interaction.

Hmm, possibly my gem CLI was old? I got via rbenv install 2.5.6; gem --version says 2.7.6.2, and it doesn't support --otp, so I guess doesn't know how to prompt either.
Building ruby 2.6.4 gave me gem 3.0.3 which does support --otp so I guess could Just Work? I'll confirm next time I make a release...

P.S. another workaround: gem release worked when I set my account MFA to "UI only" level. This is weaker but better than nothing.

[additional search keywords: 2FA, OTP]

As you can see from the command, I ran both minor and major but the gem only increments the patch.

Note:

gem bump --version 0.3.0 works fine though

I don't know how this happened, but gem release 0.6.0 has started pushing the wrong versions of my gems to rubygems.org. Here is one example

∴ gem bump --tag --release
Bumping flag_shih_tzu from 0.3.9 to version 0.3.10
Creating commit
[master f673691] Bump to 0.3.10
 1 file changed, 1 insertion(+), 1 deletion(-)
Pushing to the origin git repository
Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 501 bytes | 0 bytes/s, done.
Total 5 (delta 1), reused 0 (delta 0)
To https://github.com/pboling/flag_shih_tzu.git
   4f60d20..f673691  master -> master
  Successfully built RubyGem
  Name: flag_shih_tzu
  Version: 0.3.9
  File: flag_shih_tzu-0.3.9.gem
Pushing gem to https://rubygems.org...
Repushing of gem versions is not allowed.
Please use `gem yank` to remove bad gem releases.

Running straight gem release works:

∴ gem release
  Successfully built RubyGem
  Name: flag_shih_tzu
  Version: 0.3.10
  File: flag_shih_tzu-0.3.10.gem
Pushing gem to https://rubygems.org...
Successfully registered gem: flag_shih_tzu (0.3.10)
Deleting left over gem file flag_shih_tzu-0.3.10.gem
All is good, thanks my friend.

It sometimes fails, esp. since it's not handling encodings atm, so it would be cool if it wouldn't create a tag before trying to build the gem.

I am trying to provide a custom message for bumping version like

gem bump patch -m '<messge>'

It throws below error

    undefined method `%' for true:TrueClass

Just add those for since 0.7.0

it went from v0.1.0.pre3 directly to v0.1.1

https://github.com/svenfuchs/simple_states/tags

:)

(using gem-release 0.3.1)

gem bootstrap -f should add

s.files = Dir.glob("{lib//,[A-Z]}")

but it actually adds

s.files = git ls-files app lib.split("\n")

(using 0.2.1)

i have some gems that are "managed" by repo and i would prefer to just push the tags with repo

When a .gemrelease file is created with, for example, a host for release:

---
release:
  host: 'http://foo.bar'

The file is picked up when issueing gem release but the file is ignored when combining the release command with another command gem bump --version 1.1.3 --release

Without the --scaffold option, gem bootstrap is pretty much redundant with gem gemspec. Why not make --scaffold the default?

I think it's much easier to remember and use this:

gem bootstrap new_gem

than this:

gem bootstrap new_gem --scaffold

And I imagine this is one of the most common use cases for gem-release.

We've been writing some gems that need to have "*_rb" at the end for the gem name

Ex.

# gem name is task_rb
lib/task/version.rb

It would be great if gem bump worked on this as well

Feature Suggestion: --date to bump the datestamp in the gemspec when bumping

This would really complete the transition from Jeweler for me. I find I forget to bump the date alot. Apparently rubygems.org uses the date from the gemspec, and not the date you push a gem. I have a bunch of consecutive releases all appearing as on the same day on rubygems, which makes it look like my code was buggy, when really I just forgot to manually bump the date.

DB:~/ruby $ bundle gem test
      create  test/Gemfile
      create  test/Rakefile
      create  test/.gitignore
      create  test/test.gemspec
      create  test/lib/test.rb
      create  test/lib/test/version.rb
Initializating git repo in /Users/denis/ruby/test
DB:~/ruby $ cd test
DB:~/ruby/test $ ls
Gemfile      Rakefile     lib          test.gemspec
DB:~/ruby/test $ gem bump
Bumping from 0.0.1 to version 0.0.2
Creating commit
/Users/denis/ruby/test/lib/test/version.rb:2: warning: already initialized constant VERSION

This is using gem 1.8.5, gem-release 0.0.16, bundler 1.0.15 and ruby 1.9.2p180. I looked around in the code.

I've been using bundler for bootstrapping my gems (bundle gem my_gem), but it hasn't been quite enough control for me. I feel like gem-release solves a lot of the issues I have with bundler in particular with give me the gem bump command which is awesome.

One of the things I really love about bundler is that is makes gems private by default. Most of the work I do is propietary, so I don't want to accidentally push a new gem to RubyGems. It would be great if gem-release had an option for this when bootstrapping a project.

This is how bundler solves the RubyGems push issue: https://github.com/bundler/bundler/blob/master/lib/bundler/templates/newgem/newgem.gemspec.tt#L19

My project dir is inside "/Users/seanmackesey/Google Drive/code/lib/ruby". When I run gem bump, I get

fatal: '/Users/seanmackesey/Google' is outside repository
The task bump could not be completed. Subsequent tasks will not be attempted.

Looks like an issue with that space.

When running gem release a success message gets printed even if the release didn't succeed (I disconnected from internet for testing purposes).

Check this line:

running gem build followed by gem push --key foo --host http://foo.host/private works.

However with a .gemrelease

release:
  key: foo
  host: http://foo.host/private

Running gem release fails, with a 401 from my gem server:

...
Pushing gem to http://foo.host/private...
Authorization key is invalid
...
Tasks: TOP => release => release:rubygem_push

Are host and key not designed to work in this manner? Documentation leads me to believe they are.

With VERSION being 0.1.0.pre2 I got:

simple_states [master] $ gem bump
ERROR:  While executing gem ... (NoMethodError)
    undefined method `sub' for nil:NilClass

When combining bump with the tag or release options, the tag and release commands attempt to work with the prior version number. Oddly, the tests cover these scenarios and pass without a problem, so there must be an issue within the tests as well.

I suspect that the gemspec file isn't truly being reloaded when invoking release and/or tag, but I haven't yet found why. I'll continue to look into this, unless you see something obvious, @svenfuchs.

By the way, issuing a "gem bump" followed by "gem release" or "gem tag" works just as expected.

It would be nice if one could integrate this gem with Rake Tasks that incorporates options.
My current workaround:

desc 'Bumps and pushes new minor version.'
task :bump_minor do
  puts 'Bumping minor.'
  cmd = 'gem bump --version minor --tag --push'
  raise 'Error bumping minor version!' unless system(cmd)
end

desc 'Bumps and pushes new major version.'
task :bump_major do
  puts 'Bumping major.'
  cmd = 'gem bump --version major --tag --push'
  raise 'Error bumping major version!' unless system(cmd)
end

desc 'Bumps and pushes new patch version.'
task :bump_patch do
  puts 'Bumping patch.'
  cmd = 'gem bump --version patch --tag --push'
  raise 'Error bumping patch version!' unless system(cmd)
end

After installing gem-release version 2.0.1, I found that all my gem commands print error message like this:

Error loading RubyGems plugin "~/.rvm/gems/ruby-2.2.4/gems/gem-release-2.0.1/lib/rubygems_plugin.rb": ~/.rvm/gems/ruby-2.2.4/gems/gem-release-2.0.1/lib/gem/release/cmds/release.rb:12: syntax error, unexpected tIDENTIFIER, expecting keyword_do or '{' or '('
...e given gemspec(s), pushes them to rubygems.org

Then I check the source code of the gem-release, seems like multi-line string syntax like <<~str is not supported on ruby 2.2.4 or lower, syntax like <<-str works just fine.

I think it will be better if you can specific the ruby version gem-release supports in the gemspec or change all the <<~str to <<-str.split("\n").map(&:lstrip).join("\n")? Now I change my local gem-release code to make it work~

THX

While attempting to extend the bump command, I encountered a nasty problem for gem-release in Ruby 1.9.x that doesn't occur in 1.8.7, REE, or jRuby. When bumping and releasing or tagging a gem at the same time (e.g gem bump -t -r), the old version number, instead of the new bumped version number, gets tagged and released. Luckily, this tends to fail, since duplicate versions can't be tagged in git or pushed up to rubygems.org.

I've created a new bump_tag_and_release branch that now illustrates the problem with a test.

Because of this bug, I've removed these options from bump and pushed out a new version of gem-release: 0.2.0.

The problem seems to be that the version loaded by Gem::Specification.load() is not getting reloaded by TagCommand and ReleaseCommand for 1.9+.

One question is whether we really want to continue to support the release and tag options for bump. This is not in my own workflow, which tends to be a separate gem bump -p followed by a gem release -t. Upon adding key and host options to bump, it was beginning to look like an alpabet soup of options - perhaps too many to use reliably.

Does anyone feel strongly about keeping release and tag in bump?

@svenfuchs - thoughts? by the way, the only reason this project is failing in travis is because of the new branch; master is fine.

I was on a branch locally when i ran gem bump --tag --release --version minor and it performed all the actions while still on that branch instead of on the master branch. I'm sure it's my fault, but it was kind of a foot gun and I thought i'd mention it since there may be something that could be done, like having an option in the config that allows you to specify which branch to perform the actions on.

It would be nice if gem-release would offer an option to also create an according new github release when using the gem release command (e.g. via gem release --github).

Github offers a simple API for this purpose. You can automatically create a new Github release using a simple POST, see https://developer.github.com/v3/repos/releases/#create-a-release.

Hi, I'm trying to use the gem like this: gem bump --tag --skip-ci --push --version patch
my current version is 0.0.1 and I'm bumping to 0.1.0
I'm expecting the tag to be set to 'v0.1.0' but instead I'm getting this output (and the tag created is the same):

bump my-gem 0.0.1 0.1.0
version lib/my-gem/version.rb 0.0.1 0.1.0
git_add lib/my-gem/version.rb
git_commit "Bump my-gem to 0.1.0 [skip ci]"
[master 128a501] Bump my-gem to 0.1.0 [skip ci]
 1 file changed, 1 insertion(+), 1 deletion(-)
git_push origin
tag my-gem 0.0.1
git_tag v0.0.1 v0.0.1
git_push origin

Gem is published. Server still sends back an error mesage.

This is for a very active gem, https://github.com/shakacode/react_on_rails

Using this repo: https://github.com/svenfuchs/gem-release

and this script:

https://github.com/shakacode/react_on_rails/blob/master/rakelib/release.rake#L64

+ [email protected]
No distRepo provided, done.
cd /Users/justin/shakacode/react-on-rails/react_on_rails && gem release
WARNING:  open-ended dependency on connection_pool (>= 0) is not recommended
  if connection_pool is semantically versioned, use:
    add_runtime_dependency 'connection_pool', '~> 0'
WARNING:  open-ended dependency on rails (>= 3.2) is not recommended
  if rails is semantically versioned, use:
    add_runtime_dependency 'rails', '~> 3.2'
WARNING:  open-ended dependency on addressable (>= 0) is not recommended
  if addressable is semantically versioned, use:
    add_runtime_dependency 'addressable', '~> 0'
WARNING:  open-ended dependency on rspec (>= 0, development) is not recommended
  if rspec is semantically versioned, use:
    add_development_dependency 'rspec', '~> 0'
WARNING:  open-ended dependency on coveralls (>= 0, development) is not recommended
  if coveralls is semantically versioned, use:
    add_development_dependency 'coveralls', '~> 0'
WARNING:  open-ended dependency on generator_spec (>= 0, development) is not recommended
  if generator_spec is semantically versioned, use:
    add_development_dependency 'generator_spec', '~> 0'
WARNING:  open-ended dependency on pry (>= 0, development) is not recommended
  if pry is semantically versioned, use:
    add_development_dependency 'pry', '~> 0'
WARNING:  open-ended dependency on pry-byebug (>= 0, development) is not recommended
  if pry-byebug is semantically versioned, use:
    add_development_dependency 'pry-byebug', '~> 0'
WARNING:  open-ended dependency on pry-stack_explorer (>= 0, development) is not recommended
  if pry-stack_explorer is semantically versioned, use:
    add_development_dependency 'pry-stack_explorer', '~> 0'
WARNING:  open-ended dependency on pry-doc (>= 0, development) is not recommended
  if pry-doc is semantically versioned, use:
    add_development_dependency 'pry-doc', '~> 0'
WARNING:  open-ended dependency on pry-state (>= 0, development) is not recommended
  if pry-state is semantically versioned, use:
    add_development_dependency 'pry-state', '~> 0'
WARNING:  open-ended dependency on pry-toys (>= 0, development) is not recommended
  if pry-toys is semantically versioned, use:
    add_development_dependency 'pry-toys', '~> 0'
WARNING:  open-ended dependency on pry-rescue (>= 0, development) is not recommended
  if pry-rescue is semantically versioned, use:
    add_development_dependency 'pry-rescue', '~> 0'
WARNING:  open-ended dependency on binding_of_caller (>= 0, development) is not recommended
  if binding_of_caller is semantically versioned, use:
    add_development_dependency 'binding_of_caller', '~> 0'
WARNING:  open-ended dependency on awesome_print (>= 0, development) is not recommended
  if awesome_print is semantically versioned, use:
    add_development_dependency 'awesome_print', '~> 0'
WARNING:  open-ended dependency on gem-release (>= 0, development) is not recommended
  if gem-release is semantically versioned, use:
    add_development_dependency 'gem-release', '~> 0'
WARNING:  See http://guides.rubygems.org/specification-reference/ for help
  Successfully built RubyGem
  Name: react_on_rails
  Version: 6.8.2
  File: react_on_rails-6.8.2.gem
Pushing gem to https://rubygems.org...
Successfully registered gem: react_on_rails (6.8.2)
Deleting left over gem file react_on_rails-6.8.2.gem
WARNING:  open-ended dependency on connection_pool (>= 0) is not recommended
  if connection_pool is semantically versioned, use:
    add_runtime_dependency 'connection_pool', '~> 0'
WARNING:  open-ended dependency on rails (>= 3.2) is not recommended
  if rails is semantically versioned, use:
    add_runtime_dependency 'rails', '~> 3.2'
WARNING:  open-ended dependency on addressable (>= 0) is not recommended
  if addressable is semantically versioned, use:
    add_runtime_dependency 'addressable', '~> 0'
WARNING:  open-ended dependency on rspec (>= 0, development) is not recommended
  if rspec is semantically versioned, use:
    add_development_dependency 'rspec', '~> 0'
WARNING:  open-ended dependency on coveralls (>= 0, development) is not recommended
  if coveralls is semantically versioned, use:
    add_development_dependency 'coveralls', '~> 0'
WARNING:  open-ended dependency on generator_spec (>= 0, development) is not recommended
  if generator_spec is semantically versioned, use:
    add_development_dependency 'generator_spec', '~> 0'
WARNING:  open-ended dependency on pry (>= 0, development) is not recommended
  if pry is semantically versioned, use:
    add_development_dependency 'pry', '~> 0'
WARNING:  open-ended dependency on pry-byebug (>= 0, development) is not recommended
  if pry-byebug is semantically versioned, use:
    add_development_dependency 'pry-byebug', '~> 0'
WARNING:  open-ended dependency on pry-stack_explorer (>= 0, development) is not recommended
  if pry-stack_explorer is semantically versioned, use:
    add_development_dependency 'pry-stack_explorer', '~> 0'
WARNING:  open-ended dependency on pry-doc (>= 0, development) is not recommended
  if pry-doc is semantically versioned, use:
    add_development_dependency 'pry-doc', '~> 0'
WARNING:  open-ended dependency on pry-state (>= 0, development) is not recommended
  if pry-state is semantically versioned, use:
    add_development_dependency 'pry-state', '~> 0'
WARNING:  open-ended dependency on pry-toys (>= 0, development) is not recommended
  if pry-toys is semantically versioned, use:
    add_development_dependency 'pry-toys', '~> 0'
WARNING:  open-ended dependency on pry-rescue (>= 0, development) is not recommended
  if pry-rescue is semantically versioned, use:
    add_development_dependency 'pry-rescue', '~> 0'
WARNING:  open-ended dependency on binding_of_caller (>= 0, development) is not recommended
  if binding_of_caller is semantically versioned, use:
    add_development_dependency 'binding_of_caller', '~> 0'
WARNING:  open-ended dependency on awesome_print (>= 0, development) is not recommended
  if awesome_print is semantically versioned, use:
    add_development_dependency 'awesome_print', '~> 0'
WARNING:  open-ended dependency on gem-release (>= 0, development) is not recommended
  if gem-release is semantically versioned, use:
    add_development_dependency 'gem-release', '~> 0'
WARNING:  See http://guides.rubygems.org/specification-reference/ for help
  Successfully built RubyGem
  Name: react_on_rails
  Version: 6.8.2
  File: react_on_rails-6.8.2.gem
Pushing gem to https://rubygems.org...
Repushing of gem versions is not allowed.
Please use `gem yank` to remove bad gem releases.
rake aborted!
Command failed with status (1): [cd /Users/justin/shakacode/react-on-rails/...]
/Users/justin/shakacode/react-on-rails/react_on_rails/rakelib/task_helpers.rb:20:in `block in sh_in_dir'
/Users/justin/shakacode/react-on-rails/react_on_rails/rakelib/task_helpers.rb:20:in `each'
/Users/justin/shakacode/react-on-rails/react_on_rails/rakelib/task_helpers.rb:20:in `sh_in_dir'
/Users/justin/shakacode/react-on-rails/react_on_rails/rakelib/release.rake:64:in `block in <top (required)>'
/Users/justin/.rvm/gems/ruby-2.3.1@react_on_rails/gems/rake-12.0.0/exe/rake:27:in `<top (required)>'
Tasks: TOP => release
(See full trace by running task with --trace)

See #1589 and Issue on RubyGems.

Small issue with bumping existing gems.

Steps to reproduce:
Create a gem with version number 2.0
Bump with gem bump -v patch

Error message:

ERROR:  While executing gem ... (NoMethodError)
    undefined method `compact' for nil:NilClass

It took me a while to figure out where the error popped up.
The problem is that the target is not being set correctly in Gem::Release::Version::Number

I have a RubyGem with another RubyGem in-repo (directly, not a submodule). The file structure looks something like:

• sinja/
  • .git/
  • Gemfile
  • lib/sinja/version.rb
  • sinja.gemspec
  • extensions/sequel/
    • Gemfile
    • lib/sinja/sequel/version.rb
    • sinja-sequel.gemspec

The gemspecs look normal, i.e. like they would if they were in separate repos. In the two Gemfiles, after the gemspec directive, I'm using the :path option to point to the relative directories for development. So something like:

# sinja/Gemfile
gemspec
gem 'sinja-sequel', :require=>false, :path=>'extensions/sequel'

# sinja/sinja.gemspec
spec.add_development_dependency 'sinja-sequel', '~> 0.1'

# sinja/extensions/sequel/Gemfile
gemspec
gem 'sinja', :require=>false, :path=>'../..' 

# sinja/extensions/sequel/sinja-sequel.gemspec
spec.add_dependency 'sinja', '>= 1.2.0.pre2', '< 2'

Here's the scoop:

• bundle install|update|exec works fine in both gemspec directories
• gem build|push works fine in both gemspec directories
• gem bump finds sinja/extensions/sequel/lib/sinja/sequel/version.rb first and uses it as the base version for both gems, updating both version.rb files to the new version (PROBLEM 1)
• gem release works fine in sinja/extensions/sequel/
• gem release in sinja/ finds sinja/extensions/sequel/sinja-sequel.gemspec first and tries to re-release it (PROBLEM 2)
• gem release sinja.gemspec emits ERROR: Gemspec file not found: sinja.gemspec (PROBLEM 3)

PROBLEM 1: How can I restrict gem bump to only work on one or the other version.rb file at a time?

PROBLEM 2: Why doesn't gem release in the top-level directory find the top-level gemspec?

PROBLEM 3: What in the blazes is going on here?

Hi,

it would be nice to have the --quiet flag for all subcommands. I currently use gem bump in a filter script for git-flow and it is a real pain to catch all output by gem bump to make sure that the filter just returns the version to use for the release.

I have a dir bin with an executable file in it. It would be nice if gem bootstrap and gem gemspec would add this to the gemspec

I guess that's

s.executables << 'foo'

when bin contains the executable file foo?

Hello.

First of all, thanks for making this gem. I was very glad when I have found it. :)

I have a question.
I want to use this gem and everything is fine. But in addition to existing functionality I also would to bump version in my changelog file.

E.g.

before

--- CHANGELOG.md	2019-10-11 13:00:11.095262564 +0300
+++ CHANGELOG.md	2019-10-11 13:00:12.455265870 +0300
@@ -1 +1,3 @@
 ## Unreleased
+
+## 0.3.1 - 2019-09-09

 Bugfixes:
  - fix 1 ...
  - fix 2

 ## 0.3.0 - 2019-09-01

Is there any way to do this? May be some way to hook into bump command somewhere between actual changing of version.rb file and making a commit.

For now I use a workaround... I write simple script which invokes gem bump --no-commit --branch, then I make changes in CHANGELOG.md and then I invoke git add and git push myself.

I will be glad to hear your thoughts.

I've been using this gem for a number of projects and really appreciate the work that has gone into it. ❤️

When generating a release, I wonder if it would be possible to also update the changelog listed in the gemspec since the last tag. Maybe in an interactive fashion, allowing the user to select, comment, and link to the commits?

I'd be willing to put some effort into this if the idea aligns with the project.

Hey, I assume this more an error on my part, but I see the following output while running gem release

Enter your RubyGems.org credentials.
Don't have an account yet? Create one at http://rubygems.org/sign_up
Email:   
Password:   
Pushing gem to https://rubygems.org...
HTTP Basic: Access denied.

I have setup my credentials for rubygems in ~/.gem/credentials and am using the correct values when running gem release.

Any ideas?

Cheers!

Unfortunately, rubygems requires a . separator instead of a - for pre-release gems. Would it be possible to update gem-release to comply with that constraint?

Ex. "0.169.0" should gem bump -v pre to "0.170.0.pre.1" instead of "0.170.0-pre.1"

See rubygems/rubygems#592 (comment) and the offending line that causes all the issues: https://github.com/rubygems/rubygems/blob/064cfaf7f5357c16a4fae04d53587fcf69b6df3f/lib/rubygems/version.rb#L219

Currently, gem-release performs git push --tags when tagging a release. If there are any commits outstanding, as there often are when bumping a version, it's necessary to perform a separate git push to get the working branch sync'd with origin.

Should we combine these commands in TagCommand ?

    def push
      say "Pushing to origin git repository" unless quiet?
      `git push origin`

      say "Pushing --tags to origin git repository" unless quiet?
      `git push --tags origin`
    end

I've always been confused as to why git forces these steps to be separate, so perhaps I'm missing something. Either way, it would be good to understand the rationale.

As discussed in #15, gem-release should allow for an entirely optional yaml configuration file named .gemrelease. This file could mirror the command / options available for gem-release. For instance:

release:
  host: http://rubygems.example.com
  key: keyname

It could also be used to disable commands:

release: disabled

This would be useful for private gems that are built from source by bundler and never pushed to a host (e.g. gem 'private_gem', :git => '[email protected]:example/private_gem.git').

When running gem release and entering credentials, I'm unable to submit my email and continue the process.

Expected: Hitting "Enter" submits my email and prompts for my password.
Actual: Hitting "Enter" injects "^M" instead of prompting for a password.

Need to add rubysl-test-unit as a dependency to make rubinius happy.

This used to work.

I'd love some help to debug this.

Script with pointer to failing line: https://github.com/shakacode/react_on_rails/blob/master/rakelib/release.rake#L51

rake release[3.0.3,false,false]                                                                                                                                                                                                                                                                                      

rm -rf /Users/justin/shakacode/react_on_rails/gen-examples/examples
cd /Users/justin/shakacode/react_on_rails && gem bump --no-commit --version 3.0.3
ERROR:  While executing gem ... (Gem::CommandLineError)
    Unknown command bump
rake aborted!
Command failed with status (1): [cd /Users/justin/shakacode/react_on_rails ...]
/Users/justin/shakacode/react_on_rails/rakelib/task_helpers.rb:20:in `block in sh_in_dir'
/Users/justin/shakacode/react_on_rails/rakelib/task_helpers.rb:20:in `each'
/Users/justin/shakacode/react_on_rails/rakelib/task_helpers.rb:20:in `sh_in_dir'
/Users/justin/shakacode/react_on_rails/rakelib/release.rake:51:in `block in <top (required)>'
/Users/justin/.rvm/gems/ruby-2.2.4@react_on_rails/bin/ruby_executable_hooks:15:in `eval'
/Users/justin/.rvm/gems/ruby-2.2.4@react_on_rails/bin/ruby_executable_hooks:15:in `<main>'
Tasks: TOP => release
(See full trace by running task with --trace)

A bit of unexpected behaviour. Perhaps it should be documented in the README or the help output, perhaps?

I expect that if I pass a name to gem bootstrap, it would use that name, create the directory and then do it's jazz. Instead it uses the current directory for the name. Whoops!