Reasoning for not supporting ruby 1.8.6 in Rails 3.0
Jeremy Evans
going to be supported on ruby 1.8.6. Considering that 1.8.6 is the
still the most popular version of ruby, this seems odd. Has the final
decision been made on this? If so, could someone explain the
reasoning behind this decision (if it's been explained elsewhere, a
link would be fine)? If not, is there anything that contributors can
do to ensure that Rails 3.0 is supported on ruby 1.8.6?
Jeremy
Michael Koziarski
along the lines of Hash#hash in 1.8.6 being a problem for us.
On another level though, 1.9 is the future of ruby, and 1.8.7 is
expressly intended to be the 1.8.x which makes it easier to handle the
migration. So preferring 1.9 and supporting 1.8.7 seems consistent
with that?
Cheers
Koz
Jeremy Evans
>
> I believe this was discussed in passing in the CI thread? Something
> along the lines of Hash#hash in 1.8.6 being a problem for us.
>
> On another level though, 1.9 is the future of ruby, and 1.8.7 is
> expressly intended to be the 1.8.x which makes it easier to handle the
> migration. So preferring 1.9 and supporting 1.8.7 seems consistent
> with that?
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?
Jeremy
Michael Koziarski
> 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.
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.
--
Cheers
Koz
Jeremy Evans
>
>> 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
Luca Guidi
--
lucaguidi.com
twitter.com/jodosha
Chad Pytel
> The present (not the future) of Ruby it's 1.9.1, honestly don't know
> why the majority (myself included) is still on the old-and-beloved
> 1.8.6.
Our primary reason is because none of the main hosting services
support 1.9. EngineYard, Rails Machine, etc. all are still on 1.8.6.
We are ready to move to 1.9 if our hosts supported it.
The way I see it, any argument for continuing support for 1.8.6 are
the same arguments that can be used to support not upgrading to Rails 3.
I'm fully in support of pushing forward in the hopes that forward
movement will prompt the rest of the ecosystem to move forward.
thanks,
-Chad
---
Chad Pytel, Founder and CEO
thoughtbot, inc.
t: 617-482-1300 x113
f: 866-217-5992
http://www.thoughtbot.com
http://www.twitter.com/thoughtbot
dreamcat four
>> The present (not the future) of Ruby it's 1.9.1, honestly don't know
>> why the majority (myself included) is still on the old-and-beloved
>> 1.8.6.
>
> Our primary reason is because none of the main hosting services
> support 1.9. EngineYard, Rails Machine, etc. all are still on 1.8.6.
> We are ready to move to 1.9 if our hosts supported it.
You can also check the REE status on passenger website. This is the
only reason people want 1.8.6 anymore. They are looking for donations,
to fund performance optimizations. More importantly what's stopping
the ruby community as a whole to move forward with these REE
contributions in 1.9? I don't understand this.
dreamcat4
drea...@gmail.com
Luca Guidi
lucaguidi.com
twitter.com/jodosha
dreamcat four
> You can safely use Passenger with Ruby 1.9.1, avoiding REE.
I wasn't asking whether you can use Passenger with 1.9.1. I'm talking
the about these REE announcements on the passenger (sorry, 'Phusion')
website: http://blog.phusion.nl/2009/05/27/ruby-enterprise-edition-third-sponsorship-campaign/
My point is that for many outside the development loop, its not
particularly clear if / when the Ruby 1.8.6 REE optimisations were
added to 1.9.1. So many people still insist on installing 1.8.6 rather
than moving forwards. The whole project situation between ruby1.9 and
REE, their respective project statuses could be clearer.
dreamcat4
drea...@gmail.com
Jeremy Evans
Yehuda,
First, thank you very much for your detailed post. I don't have any
reason to believe that migrating to 1.8.7 will be difficult. It's
just that running on 1.8.7 makes it more likely that I'll accidently
use features that aren't supported on 1.8.6, and I want other
libraries I develop (mainly Sequel) to support 1.8.6.
I'm glad that Rails 3 is requiring ruby 1.8.7 for technical reasons
and not just to try to push the community in a certain direction. It
doesn't look like it would be worth it to try to support ruby 1.8.6 in
Rails 3.
Thanks,
Jeremy
Rick DeNatale
>
> On Wed, Sep 9, 2009 at 12:17 AM, Yehuda Katz <wyc...@gmail.com> wrote:
>> 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
> First, thank you very much for your detailed post. I don't have any
> reason to believe that migrating to 1.8.7 will be difficult. It's
> just that running on 1.8.7 makes it more likely that I'll accidently
> use features that aren't supported on 1.8.6, and I want other
> libraries I develop (mainly Sequel) to support 1.8.6.
The answer to this is to test your code against multiple versions.
There are tools such as multiruby (part of ZenTest) which make this
easy. I currently test my ri_cal gem against 1.8.6, 1.8.7 and 1.9.1
> I'm glad that Rails 3 is requiring ruby 1.8.7 for technical reasons
> and not just to try to push the community in a certain direction.
I think it's more of a pull than a push.
I still think that 1.8.6 needs to live on, only because there are
still apps out there with dependencies (like old Rails versions) which
require it, for which migration to a newer version is not justifiable.
For a new app, particularly one written to Rails 3, I'd probably just
start with Ruby 1.9. I'm still not convinced that 1.8.7 is either
fish or fowl.
--
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Joris Verschoor
similar thing that happened with java 1.2 1.4 and 1.5.
Come on guys, these are all open source projects. If something isn't
working on a newer version, how much work would it be to get it to
work?
just my 2cents
Jeremy Evans
>
> I think if we don't go to ruby 1.9, ruby and rails will get stuck in a
> similar thing that happened with java 1.2 1.4 and 1.5.
Certainly, supporting the latest version of ruby is a good thing.
However, forcing people to upgrade their ruby installation without a
solid technical reason is a bad practice to get into. If people want
to use 1.9, it should be on 1.9's own merits, not simply because Rails
is forcing them to.
At some point, there may be technical reasons that make it difficult
to support the then current version of Rails on ruby 1.8.x, just as
there are current technical reasons that make it difficult to support
Rails 3 on ruby 1.8.6. Until that point, Rails should support both
1.8.x and 1.9.x, IMO.
Jeremy
Jason King
The rub with that is that you end up with a lowest common
denominator. A bunch of new features in 1.9 which aren't used because
of backward compatibility. Pretty soon we're where Perl is with
library code that's huge with version conditionals strewn through it.
I don't understand the issue. If someone wants to stick with 1.8.x
then why not also stick with Rails 2.x?
The "solid technical reason" is that developers have finite amounts of
time, I'd rather that limited amount of time is spent on high value
activities. Offering options for people not willing to upgrade (for
no solid technical reason) seems like a low value activity to me.
--
Jason
Rick DeNatale
>
> On Wed, Sep 9, 2009 at 2:32 PM, Joris Verschoor <jbver...@gmail.com> wrote:
>>
>> I think if we don't go to ruby 1.9, ruby and rails will get stuck in a
>> similar thing that happened with java 1.2 1.4 and 1.5.
>
> Certainly, supporting the latest version of ruby is a good thing.
> However, forcing people to upgrade their ruby installation without a
> solid technical reason is a bad practice to get into. If people want
> to use 1.9, it should be on 1.9's own merits, not simply because Rails
> is forcing them to.
Nobody is forcing anyone to upgrade to Rails 3 either.
>
> At some point, there may be technical reasons that make it difficult
> to support the then current version of Rails on ruby 1.8.x, just as
> there are current technical reasons that make it difficult to support
> Rails 3 on ruby 1.8.6. Until that point, Rails should support both
> 1.8.x and 1.9.x, IMO.
You can only kick so many old cans down the road for so long.
There's a cost of maintaining compatibility with old versions of
anything, it's not just 1.8.x and 1.9.x, it's 1.8.6.x, 1.8.7.x, 1.9.x
and soon apparently 1.8.8.x.
And it's not just Rails, it's all the various gems, plug-ins, etc.
That's a major reason making the transition to 1.8.7 and more so to
1.9.x was difficult. 1.8.7 introduced syntax changes which required
some amount of compatibility patches, 1.9 introduced a superset of
those syntax changes along with a new internal implementation which
broke gems with C extensions, this is gradually being addressed,
either by bringing old gems and plugins along or by replacements
providing the same or more function.
From what I understand, the plan for Rails 3 is to provide support for
1.8.7+, and I think that that's the right thing to do, in order to
allow Rails, Ruby and the sea of open source which comprises the Ruby
landscape progress and evolve.
Chad Pytel
> working on a newer version, how much work would it be to get it to
> work?
I'm not sure if you're being sarcastic here, but I'll bite. It's very
often quite a bit of work. It's even more work to then maintain 1.8.6
and 1.8.7 compatibility once you do it.
While, as I've already stated, I think supporting 1.9 is very
important - please don't minimize the effort that it will take
everyone in the community to do it.
Ryan Bigg (Radar)
Will Bryant
> 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?
There is that ERB comment issue, whereby it turns out (according to
the official documentation) that we were not actually allowed to write
things like:
<% elsif customer.oddball? # we get lots of these guys %>
which is pretty widely used and worked perfectly just fine most or all
of the way through the 1.8.6 series but doesn't on 1.8.7 (see
http://www.ruby-forum.com/topic/154835 and
https://rails.lighthouseapp.com/projects/8994/tickets/955-ruby-187-and-erb-problem-3).
This is a really nasty one because, really, there's no reason why this
shouldn't be made to work, and when it stops working, it doesn't
break.... you just lose a whole big chunk of output from your views.
A bit silent and nasty for many of us.
The Ruby guys don't seem to be inclined to change it back, so unless
one already has full test coverage for each and every case/path in
every one of your views files, this is something important to scan for
when upgrading to 1.8.7.
You could get an approximate test with just grep if you're careful
about the conditions (for example, <%# this is a legitimate ERB
comment %> but <% # this isn't %>, and be careful about multiple
blocks on one line), so if you are moving the whole team to 1.8.7 and
so just need to do a once-over pass, that's probably fine.
But that will tend to produce false alarms, for example if you have
other uses of hashes on the same line, such as <% s =
'/test.html#anchor' %>, so it's not much help if you want an automated
test to run in continuous integration or need to audit a large number
of views. I'm knocking up a bit of code to do it properly using
ruby-parser, if people are interested I'll sort out a good way to
package and release it.
Adam Milligan
documented as such. You can't reasonably expect language providers to
support behavior that they've explicitly declared as invalid, and you
can't reasonably expect framework providers to stick with a language
version because you've chosen to depend on a particular incarnation of
undefined behavior. This is directly akin to depending on the order
of the contents of a hash, or referencing values in freed memory.
There are reasonable reasons to want Rails 3.0 to work on Ruby 1.8.6,
but this isn't one of them.
Incidentally, the behavior in at least some versions of 1.8.6 is
consistent with 1.8.7.
On Sep 13, 5:23 am, Will Bryant <will.bry...@gmail.com> wrote:
> On Wed, Sep 9, 2009 at 7:17 PM, Yehuda Katz <wyc...@gmail.com> wrote:
> > 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?
>
> There is that ERB comment issue, whereby it turns out (according to
> the official documentation) that we were not actually allowed to write
> things like:
>
> <% elsif customer.oddball? # we get lots of these guys %>
>
> which is pretty widely used and worked perfectly just fine most or all
Jeremy Kemper
jeremy
Will Bryant
out that there's an upgrade issue that people need to be aware of,
which is what Yehuda was asking for. Kindly re-read my post.
But since you mention it, I can expect them to at least give an error,
rather than silently losing code. Language providers do not
necessarily have the burden of making everything that used to work
continue to work (although some have chosen to do so), but they are
generally expected to change things in a way that lets people at least
notice the problems promptly.
Jeremy Kemper
tag contains a comment.
In 1.8.7, raise an error.
jeremy
Mukund
On Sep 10, 4:40 am, "Ryan Bigg (Radar)" <radarliste...@gmail.com>
wrote: