Why not start testing edge rails against Ruby 1.9 in the continuous integration build (as well as on local dev machines, of course), so that breaking changes could be caught well before ruby 1.9 goes public.
- Rob On 10/23/07, Jeff <[EMAIL PROTECTED]> wrote: > > On Oct 23, 6:40 pm, "Michael Koziarski" <[EMAIL PROTECTED]> wrote: > > We make quite a bit of use of class variables and in some places > > (mostly configuration variables) we rely on them being available in > > subclasses. In the event that that's no longer the case we'll have to > > ship a maintenance release which works around this. > > Methinks this could be a p.r. nightmare. If I understand correctly, > upgrading a server's Ruby from 1.8 to 1.9 will break Rails apps that > were frozen to a specific Rails gem (which we all do, because that's a > recommended practice and is normally exactly the right thing to do to > shield an app from Rails version changes). > > I think ruby core needs to make it well publicized that 1.9 has > breaking changes in it. > > I fear the minor version number change won't communicate that as well > as "2.0" might. And then they will think Rails did something wrong. > > My understanding from the ruby list is that 1.9 won't see the light of > day until the 2nd half of 2008, so fortunately we do have time to > figure out a solution and/or broadcast the warnings far in advance. > > Jeff > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
