Rspec-1.3.1.rc and rspec-rails-1.3.3.rc are released!

Testing RSpec
1

rspec-1.3.1.rc and rspec-rails-1.3.3.rc are released!

These are release candidate gems for updates 1.x series, including some
bug fixes and deprecation warnings for functionality that will be
removed in rspec-2.

Barring unexpected complications, I’ll release final versions of these
gems within the next week.

Cheers,
David

===================================================================
rspec-1.3.1 (rc)

  • enhancements

    • Array =~ matcher works with subclasses of Array (Matthew Peychich &
      Pat M.)
    • config.suppress_deprecation_warnings!

  • bug fixes

    • QuitBacktraceTweaker no longer eats all paths with ‘lib’
      (Tim H. - #912)
    • Fix delegation of stubbed values on superclass class-level methods.
      (Scott T. - #496 - #957)
    • Fix pending to work with ruby-1.9

  • deprecations

    • share_as (will be removed from rspec-core-2.0)
    • simple_matcher (will be removed from rspec-core-2.0)

===================================================================
rspec-rails-1.3.3 (rc)

  • enhancements

    • replace use of ‘returning’ with ‘tap’ (to quite rails-2.3.9
      deprecation warnings)

  • bug fixes

    • support message expectation on template.render with locals (Sergey
      Nebolsin). Closes #941.
    • helper instance variable no longer persists across examples
      (alex rothenberg). Closes #627.
    • mock_model stubs marked_for_destruction? (returns false).
      ===================================================================
2

Hi David,

On 3 Oct 2010, at 23:41, David C. wrote:

These are release candidate gems for updates 1.x series, including some bug fixes and deprecation warnings for functionality that will be removed in rspec-2.

I’m having to maintain a fork of RSpec just so that I can revert the
commit which caused the breakage in
Lighthouse - Beautifully Simple Issue Tracking. What
are the chances of getting the failing example from that ticket into
1.3.1, along with either a reversion of the offending commit or (much
better) an actual fix? To me this is a significant compatibility issue
since it used to work in RSpec 1.2.9 and still does work in RSpec 2. I
just don’t understand enough about how this part of RSpec works to do a
proper fix myself, but from a selfish perspective a revert of the bad
commit is better than no fix at all.

Cheers,
-Tom

3

On Oct 5, 2010, at 2:32 AM, Tom S. wrote:

Hi David,

On 3 Oct 2010, at 23:41, David C. wrote:

These are release candidate gems for updates 1.x series, including some bug fixes and deprecation warnings for functionality that will be removed in rspec-2.

I’m having to maintain a fork of RSpec just so that I can revert the commit which caused the breakage in Lighthouse - Beautifully Simple Issue Tracking. What are the chances of getting the failing example from that ticket into 1.3.1, along with either a reversion of the offending commit or (much better) an actual fix? To me this is a significant compatibility issue since it used to work in RSpec 1.2.9 and still does work in RSpec 2. I just don’t understand enough about how this part of RSpec works to do a proper fix myself, but from a selfish perspective a revert of the bad commit is better than no fix at all.

Hi Tom,

Looks like it does work in rspec-2:

As for rspec-1, if it were a simple matter of reverting the commit, I’d
do it, but the revert fails w/ merge errors and I don’t have the time to
debug that right now. So 1.3.1 is going to go out without addressing
this unless someone else submits a patch.

Wish I could give you better news, but my plate is piled high and there
is only so much time in a day.

Cheers,
David