Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
http://rspec.info/blog/2013/07/the-plan-for-rspec-3/#zero_monkey_patching_mode > we do want to encourage people to switch to the new syntax, so we plan to make RSpec 3 print a warning on first usage of any the old syntax methods (should, should_not, should_receive, etc) unless the should syntax has been explicitly enabled. This should nudge folks towards the new syntax while keeping RSpec friendly to new users and will pave the way for the old syntax to be disabled by default in RSpec 4. > zero-monkey-patching mode for RSpec... We plan for these config options to become the defaults in RSpec 4.0, so that RSpec 4.0 will have zero monkey patching out of the box. As for "disabled by default" vs "completely removed" and "default, out of the box" vs "impossible" I can only say that RSpec 4 was probably planned to be released earlier, as: > we'll probably be dropping support for 1.8.7 in RSpec 4 but we've also dropped 1.9, 2.0, 2.1 and 2.2 rspec/rspec-core#2301 (comment) > In RSpec 4, we plan to extract all monkey patching from RSpec and move it into a separate gem, so that monkey patching is opt-in instead of opt-out and users have to explicitly install and load a gem to get it. `rspec-should` (or `rspec-monkey` as it's also about exposing example group DSL in the top-level/Module?) will be released later. Those using the monkey-patched `should` syntax are not encouraged to update to RSpec 4 until this gem is extracted. Those using the globally-exposed DSL are encouraged to use `RSpec.describe`/`RSpec.shared_examples_for` instead.
- Loading branch information