TODO

* Decide a way to test methods that are only visible given a specific
  command-line option. For example, Kernel#gsub with -n/-p on 1.9.
* Decide how to guard bugs that are regressions. IOW, if a bug appears in 1.9
  but not in 1.8, we should be able to guard it from 1.9 while still yielding
  to 1.8.
* Look at automating discovery of guarded bugs which have been fixed.  Use
  mocks for all Math functions that coerce with #to_f; currently a fixture
  is used.
* Consider filing ticket about 1.8.6's ARGF#readlines returning nil at the end
  of a stream. 1.8.7+ returns an empty Array, as the rdoc since 1.8.6 implies.
* File ticket: $ ruby86 -e 'p ARGF.skip'
  -e:1:in `skip': undefined method `close' for false:FalseClass (NoMethodError)
  from -e:1 (Reported as bug #1653; update spec based on outcome).
* Use the variable matchers which take into consideration the difference of the
  returned type of variable name. Which is String on 1.8 and Symbol on 1.9.
  Examples include: have_constant, have_instance_variable, etc.
* Ascertain backport policy for 1.9.2 -> 1.9.1 -> 1.8.7. Are bug fixes merged
  backwards by default, or is it all case by case? The answer will inform how
  we handle ruby_bug guards that pass on HEAD, but fail on earlier versions.
* Replace Infinity/NaN hacks with the new helpers.
* Think about how we can support exhaustive tests of certain features.
* Specify 'public' and 'protected' keywords.

# Windows
==========
* Run core/kernel/require_spec.rb on Windows, check all tests pass; fix as
  necessary.
* Confirm that core/dir/home_spec.rb passes on Windows under 1.9.

# 1.8
=========
* File ticket about Rational(1, 2) != Rational.new!(4, 8) on 1.8...

# 1.9
=========
* Methods that could modify a frozen receiver should raise RuntimeError, even
  if the method's arguments are such that no modification would occur.
* The inclusion of 'rational' by default has resulted in ZeroDivisionErrors
  being raised where they previously weren't. What is the rule of thumb in
  determining whether this outcome is intentional?
* Unify treatment of bugs after conversation with brixen. Bugs that occur only
  in 1.9 shouldn't be guarded; we just tag them with the bug number, e.g. " mspec
  tag --add 'fails(#555)' -e 'the failing stuff' path/to/spec".
* Spec Ripper.
* 1.9 defines methods such as instance_eval on BasicObject; not Kernel as in
  1.8. Do we need to share these specs so that the methods are specified in
  the correct place?
* Determine how we're going to specify the vast Gem module...
* Specify require_relative
* Share Enumerable#join with Hash#join once Enumerable#join is more stable.