rspec users - Oct 2010 - rspec-1.3.1.rc and rspec-rails-1.3.3.rc are released!

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
Maddox)
  * config.suppress_deprecation_warnings!

* bug fixes
  * QuitBacktraceTweaker no longer eats all paths with ''lib''
    (Tim Harper - #912)
  * Fix delegation of stubbed values on superclass class-level methods.
    (Scott Taylor - #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).
===================================================================

Hi David,

On 3 Oct 2010, at 23:41, David Chelimsky 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
https://rspec.lighthouseapp.com/projects/5645-rspec/tickets/1009. 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

On Oct 5, 2010, at 2:32 AM, Tom Stuart wrote:
> Hi David,
> 
> On 3 Oct 2010, at 23:41, David Chelimsky 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
https://rspec.lighthouseapp.com/projects/5645-rspec/tickets/1009. 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:
http://github.com/rspec/rspec-mocks/commit/b8135d5d8d04930f09d606a96c2d84be910a12f2

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