Hi, Not long ago on ruby-core, matz revealed that the ruby core team is making a shift in how they designate production vs. experimental versions of Ruby. In the past rubys with even numbered minor version numbers have been production, and those with odd numbered minor versions have been experimental. So the working assumption has been that 1.9 will continue to be experimental, and 2.0 would be the next production release. However, it now seems the the ruby core team will be using the existence of a teeny version number to indicate production status, and there will be an upcoming ruby 1.9.1 which will be considered production. What this seems to mean is that when 1.9.1 is released, the api/language changes from 1.8 will be frozen and subsequent 1.9.x releases will focus on improving the implementation. The expectation and hope would be that at this point, production code which uses ruby would start adapting to Ruby 1.9 with the release. The sense is also that 1.9.1 is probably going to be this years Christmas present from the ruby core team. With that all said, I''ve been wondering what some of the 1.9 changes would mean to Rails. In particular, since there''s also been recent discussion on ruby-talk about it, I''m thinking about the change to the semantics of class variables. In Ruby 1.9, class variables won''t be inherited by subclasses, instead it seems as if they act more like class instance variables which are magically visible in instance methods. I notice that Rails seems to make significant use of class variables, but I''m not sure how much it relies on their inheritablility. I figure that this is a more appropriate question to raise here than on the general rails group. Comments? -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> With that all said, I''ve been wondering what some of the 1.9 changes > would mean to Rails. > > In particular, since there''s also been recent discussion on ruby-talk > about it, I''m thinking about the change to the semantics of class > variables. In Ruby 1.9, class variables won''t be inherited by > subclasses, instead it seems as if they act more like class instance > variables which are magically visible in instance methods. > > I notice that Rails seems to make significant use of class variables, > but I''m not sure how much it relies on their inheritablility. I > figure that this is a more appropriate question to raise here than on > the general rails group.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. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 23, 6:40 pm, "Michael Koziarski" <mich...@koziarski.com> 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 <cohen.jeff@gmail.com> wrote:> > On Oct 23, 6:40 pm, "Michael Koziarski" <mich...@koziarski.com> 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 24, 2007, at 3:03 AM, Rob Sanheim wrote:> > 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.I don''t think we have full coverage, so that''s not going to work. Besides, the tests might have to re-written for 1.9 too. Manfred --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> I don''t think we have full coverage, so that''s not going to work.We do, however, have > 0 coverage ;) If someone can set up a 1.9 test environment, I think that''s a good step in the right direction.> Besides, the tests might have to re-written for 1.9 too.I wouldn''t anticipate any breakage of that magnitude, jeremy''s been committing 1.9 related changes for a while so we''re not flying completely blind. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 10/24/07, Michael Koziarski <michael@koziarski.com> wrote:> > > I don''t think we have full coverage, so that''s not going to work. > > We do, however, have > 0 coverage ;) If someone can set up a 1.9 test > environment, I think that''s a good step in the right direction. > > > Besides, the tests might have to re-written for 1.9 too. > > I wouldn''t anticipate any breakage of that magnitude, jeremy''s been > committing 1.9 related changes for a while so we''re not flying > completely blind.If the usage of inherited class variables in Rails is significant, might it not be something to be raised with the ruby core team before they finalize the change? It''s not clear to me that the change is actually a good one, although I''m not much of a direct user of class variables myself. If this is something that the rails core team thinks should be raised, the time is ripe. I''m not sure what if anything might be set in stone by rubyconf in Charlotte next week. If this is a tempest in a teapot, then feel free to ignore my concerns. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> If the usage of inherited class variables in Rails is significant, > might it not be something to be raised with the ruby core team before > they finalize the change? It''s not clear to me that the change is > actually a good one, although I''m not much of a direct user of class > variables myself.Class variables are already fairly restrictive and we use our own ''class inheritable attributes'' in most places. Any changes will probably be for the better and we''ll be able to work around them with our own macros.> If this is something that the rails core team thinks should be raised, > the time is ripe. I''m not sure what if anything might be set in stone > by rubyconf in Charlotte next week.I won''t be in charlotte as I''ve had just about enough of the long haul from Auckland to San Francisco. But I know some of us will be and perhaps it can be discussed over dinner :). -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---