On 21 January 2011 13:56, David Chelimsky <dchelim...@gmail.com> wrote:
> 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
>
Whilst its very noble to try and follow the ruby gems document to the
letter, some consideration has to be given to the overall effect of rapidly
changing major version numbers on the project. RSpec has a very large user
base, a close tie in with Rails major versions, in particular the idea to
Rails 3 should use RSpec 2, and a history of changing major versions very
infrequently with major consequences to the vast majority of users. This I
think is a fair assessment of RSpec's context re version numbers. To move to
RSpec 3, for such a small change would be completely out of character for
the project. To end up in 4 months time with RSpec 9 would be very
detrimental to the projects reputation.
So I think the pragmatic approach is a minor release with a big caveat in
the history and a big announcement on the mailing list
All best
Andrew
--
------------------------
Andrew Premdas
blog.andrew.premdas.org
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
