I'm not arguing that we stick with 1.8.6 for Rails 3.0, I'm pointing 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. On Wed, Sep 16, 2009 at 8:49 AM, Adam Milligan <[email protected]> wrote: > > This comment example is invalid ERB, and is relatively clearly > 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 <[email protected]> wrote: >> On Wed, Sep 9, 2009 at 7:17 PM, Yehuda Katz <[email protected]> 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 >> of the way through the 1.8.6 series but doesn't on 1.8.7 >> (seehttp://www.ruby-forum.com/topic/154835andhttps://rails.lighthouseapp.com/projects/8994/tickets/955-ruby-187-an...). >> >> 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. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
