]On 22 January 2011 09:47, David Chelimsky <dchelim...@gmail.com> wrote:
> On Fri, Jan 21, 2011 at 5:13 PM, Andrew Premdas <aprem...@gmail.com>
> wrote:
> > 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
>
> The goal here is to set a new standard that people can count on. Right
> now, many rspec users count on upgrades breaking things, which is not
> exactly the sort of reliability I'd like to convey.
>
> I want to eliminate any perception of a binding between Rails and
> RSpec releases. It's one thing to have a compatibility mapping
> (rspec-2 supports rails >= 3), but it's entirely another to assume
> that we need to wait for rails-4 to release rspec-3.
>
Of course, and I wasn't suggesting that rspec3 should wait for rails4.
>
As for the timing of major releases, I'm thinking more like a major
> release every 6 months to a year, not 7 more in 4 months time :) And,
> again, the idea is that major releases won't be quite so major. They
> simply indicate that there are breaking changes in the release, and
> you should upgrade to that release knowingly.
>
> My concern is that people (especially project owners and people further
away from the project) seeing RSpec moving quickly to 3, 4, 5 will judge the
project unstable and think that each change will involve a similar amount of
work as moving from rspec1 to 2, or even Rails 2.x to 3.x. This would be a
good (in innaccurate) argument for choosing a more 'stable' test tool.
A major release every 6 months to a year seems reasonable, but I'm not
convinced you could keep to this if this particular change and changes like
it caused a major release.
I've found a solution that I think serves these goals well: rspec-2.5
> will add the --skip-bundler option and deprecate the implicit addition
> of 'bundle exec'. It will still work as 2.4 does, but users will see a
> deprecation warning explaining to use the autotest/bundler plugin or
> the --skip-bundler option. When either of those options is applied,
> the deprecation warning goes away.
>
The add an option and a deprecation warning approach seems an excellent
compromise to prepare for a more permanent solution in 3.0. Perhaps there is
a pattern here to be applied to similar changes, thus giving advanced users
time to use the new functionality in anger, and get feedback over a period
of time.
All best
Andrew
>
> When it comes time to release rspec-3, rspec-autotest will be
> extracted from rspec-core, the --skip-bundler will no longer do
> anything, and you'll see a message saying so. At that point, you
> either use the autotest/bundler plugin or not.
>
> Thoughts?
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
--
------------------------
Andrew Premdas
blog.andrew.premdas.org
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
