[rspec-users] major release required?

David Chelimsky dchelimsky at gmail.com
Fri Jan 21 08:56:12 EST 2011

On Jan 19, 2011, at 6:48 AM, Rick DeNatale wrote:

> 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
> file.


> 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.

Correct. And I'm trying to establish a consistent pattern in releases so people can trust that minor and patch releases won't introduce breaking changes. This one is a bit of an outlier, and I started this thread to see what ppl thought of treating it as such, but the more I think of it, the more I'm convinced that this should not be an exception.

> 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.

That's unfortunate. Whether or not I do an rspec-3 release now, adherence to Rubygems' rational versioning policy will likely result in an rspec-3 release in much less time than it took us to get to rspec-2. When it comes out, rspec-3 will not represent a major rewrite or significant API or functional changes. It will simply be an indicator that there are backward-incompatible changes in that release and you should accept that upgrade consciously and carefully.

> 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.

Thanks for being willing to help out. We should probably hit guard-rspec up with this now, though, so when rspec-3 does come along guard users don't have to take a hit at that point. Do you want to drive that?

> 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
> footing.

Definitely in the plan for rspec-3: https://github.com/rspec/rspec-core/issues/issue/285.


More information about the rspec-users mailing list