Hey Jeremy,
I apologize for the delay.
The basic idea is that there are a number of issues in Ruby 1.8.6 that are
simply not going to be fixed (see
http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7/ChangeLog for a complete
list), and targeting 1.8.6 means always having to make sure that new
features are not implicated by those old bugs. Sure, the community could
spend a lot of time and energy writing a (slow and brittle) shim, but that
would mean that the community would be forced to do that every time we ran
into a new issue. Also, since Rails major releases come out around once
every two years, choosing to stick with 1.8.6 now would mean we'd be stuck
with 1.8.6 until approximately 2012. Given the number of bugfixes in 1.8.7,
I'd really not have to do that.
Some bugfix examples include:
- Hash#hash, #eql and Array#hash, #eql: Both of these do not include
recursive Hashes, which means they cannot be used as Hash keys internally in
1.8.6. This significantly impedes our ability to use the only caching
primitive available in Ruby. For instance, we use a Hash to cache template
lookup for ["template_name", {:formats => [:html], :locale => [:en]},
"controller_name", partial?]. In order to correctly shim this in 1.8.6,
every template lookup would be forced to do an expensive in-Ruby calculation
that would almost entirely negate the cache. I've done a significant amount
of performance work in Rails 3, and this issue constantly crops up.
- A ton of improved Windows support, especially for files. Both Pathname and
File have a significant number of improvements to improve Windows issues.
This is an area where being able to rely on more correct behavior will avoid
bugs that could have otherwise happened and might have ended up uncaught.
These bugs are almost always subtle, and don't always show up in CI (that
is, once we have reliable Windows CI).
Additionally, there are some new features that we'd like to be able to use
at some point.
- Enumerators. The Rack API requires an object that respond_to?(:each) as
the body. Since Enumerators use that same API, there is potentially an
opportunity for simplification and optimization using this API. I would like
to be able to experiment with this feature, which is very hard to emulate
(especially with exact fidelity), in 1.8.6.
- Improved information for error messages. Kernel#__method__ and
Kernel#__callee__ have been added, which provide us with some information we
can use to present better error messages. Additionally, Method and
UnboundMethod now have #name and #owner, which give us more information
about methods than we had before, and can permit us to provide better error
information.
- Native String#chars and #instance_exec. These are emulated ok in Rails for
Ruby 1.8.6, but the native versions are significantly better, more
performant, and less flaky, and being able to rely on the native
implementation would be convenient. This is obviously less important than
the bugfixes above.
Finally, Ruby 1.8.7 does not appear to provide backward-compatibility
issues. For instance, WePlay, which has a significant, complex app, had a
lot of trouble porting their app to Ruby 1.9, but basically zero problems
with Ruby 1.8.7. The few issues that people did have were rapidly and
diligently resolved by the Ruby team. Do you have any reason to believe
otherwise?
-- Yehuda
On Fri, Sep 4, 2009 at 10:59 PM, Jeremy Evans <[email protected]>wrote:
>
> On Fri, Sep 4, 2009 at 6:58 PM, Michael Koziarski<[email protected]>
> wrote:
> >
> >> Assuming the community provides patches that allow Rails to continue
> >> working on 1.8.6, would the core team consider supporting 1.8.6?
> >>
> >> To put it another way, if there aren't hard technical problems in
> >> supporting 1.8.6, why force 1.8.7 down the community's collective
> >> throat?
> >
> > My understanding is that there *are* hard technical problems present
> > today. Yehuda and jeremy have more info, and perhaps the relevant
> > problems can be backported to 1.8.6 making this a non-issue.
>
> Hopefully Yehuda or Jeremy can take a moment to explain what the problems
> are.
>
> > I don't think anyone wants to prematurely abandon a functioning ruby,
> > however we also don't want to continue supporting older interpreters
> > forever. Even if we do support 1.8.6 for 3.0, the end of the line
> > *is* coming, and we'd be best off preparing for that rather than
> > attempting to hold back the tide of progress.
>
> I think as long as ruby 1.8.6 is officially supported in terms of
> backporting patches and security fixes (which Kirk Haines of EY is
> handling), it's a valid candidate for Rails support.
>
> FWIW, Rails currently supports ruby 1.8.2
> (http://rubyonrails.org/download), so there is precedent for
> supporting interpreter versions that are 4 years old.
>
> Jeremy
>
> >
>
--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
