On Jan 19, 2011, at 6:48 AM, Rick DeNatale wrote:
> On Tue, Jan 18, 2011 at 1:31 PM, David Chelimsky <dchelim...@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 <dchelim...@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.
Correct.
> 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.
Cheers,
David
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
