On Jan 19, 2011, at 6:48 AM, Rick DeNatale wrote:
- in lib/autotest/rspec2.rb
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.
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
Definitely in the plan for rspec-3: