[rspec-users] major release required?

Rick DeNatale rick.denatale at gmail.com
Wed Jan 19 07:48:20 EST 2011

On Tue, Jan 18, 2011 at 1:31 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Jan 18, 2011, at 11:08 AM, Rick DeNatale wrote:
>> On Tue, Jan 18, 2011 at 9:15 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>>> Hi all,
>>> Since the release of rspec-2.0, I've been following Rubygems' rational versioning [1] as closely as possible. Patch releases (2.4.x) have only had bug fixes, and minor releases (2.x.0) have had new features, but no (intentionally) backward incompatible changes, which should require a major (3.0) release.
>>> The autotest extension in rspec-2.0 prefixes the command it generates with 'bundle exec' if it sees a 'Gemfile' in the project root directory. It turns out that this is not universally helpful, so there was a request to have an opt-out.
>>> It also turns out that autotest has a bundler plugin that prefixes the command with 'bundle exec'. To use an autotest plugin, you just require it in a .autotest file in the project root. In this case:
>>>  require 'autotest/bundler'
>>> I think the right thing to do is to rely on the autotest plugin, but I also think that this would require a 3.0 release, which feels a bit grand for this situation. My question to you is: do you think this warrants a major (3.0) release, or would it be an acceptable exception to the rule (assuming proper fanfare and documentation)?
>> Can't something be done here as a non-breaking change?  I can see two things.
>> 1) add the requested option, I think this is optional
>> 2) in lib/autotest/rspec2.rb
>>   def using_bundler?
>>    File.exists?('./Gemfile') && !defined Autotest::Bundler  # and
>> also check for the option if you decide to do #1
>>  end
> I actually did implement a --skip-bundler option (not yet released), but it has to be passed like this:
> autotest -- --skip-bundler
> Considering that this is a total hack, and that I'd be removing it at the next major release anyway, I really don't want to introduce a hack on top of a hack. I'd sooner do a 3.0 release now.

I'm still trying to understand what you are proposing to change, and
what it breaks.

I guess you are proposing that the  rspec autotest extension would
never prefix the rspec command with 'bundle exec' and this would break
folks using autotest with rspec who haven't changed their .autotest

And that you think that you should bump the whole rspec suite to
version 3 because of this? I guess this is because the autotest
'extension' isn't really an extension, it's in rspec-core.

What about those of us using other alternatives to autotest, e.g.
guard?  I just looked at the guard code and changing rspec as a whole
to version 3 would break guard since it checks specifically for rspec
version 1 vs. 2 in order to determine whether to use 'spec' or 'rspec'
as the base command.

If you bump rspec to v3 because of this, it looks like guard users
will need to freeze on rspec 2, at least until the author of
guard-rspec catches up.  I guess that's OK unless the latter takes too
long, and rspec continues to improve only on the version 3 branch.
That probably wouldn't happen, and if it does I could fork guard-rspec
myself I guess.

But if you do, I think you should also break out the autotest
extension into a separate gem which is NOT required by rspec-core,
much like Rails 3 broke out 'most-favored' things like Test::Unit and
put alternatives like, say RSpec, and Cucumber on more of an equal

Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

More information about the rspec-users mailing list