From: "NARUSE, Yui" Date: 2011-01-21T17:39:49+09:00 Subject: [ruby-core:34707] Re: [Ruby 1.8-Feature#4239] Let's begin a talk for "1.8.8" -- How's needed for surviving 1.8? 2011/1/21 Zeno Davatz : > Issue #4239 has been updated by Zeno Davatz. > I still think it is very important that 1.8.8 is a _bridge_ to Ruby 1.9.2. It should not be a dead-end road to stable heaven. It should be a bridge to Ruby 1.9. I think Ruby 2.0 can break everything but not 1.9. 1.9 should be the very stable version but should _also_ cover everything that is in 1.8. But again, obviously I do not understand the release cycle of Ruby and I also think it is not that clear as to when one can expect things to be broken. When I read about Ruby 1.9.2 I get the impression is solves all my problems. Well if it breaks with old habits then it creates more problems. So something feels wrong for me. You have some misunderstanding. 1.9 is what breaks 1.8 compatibility, and 2.0 is intended to be compatible with 1.9. You may understand by this explanation: 1.9.2 is 1.99.2 like Gnome's versioning rule. > Switching from Ruby 1.8.6 to Ruby 1.9.2 should be made hassle-free. So incompatibility between 1.8.x and 1.9.x is unavoidable and intended. Though 2.0.x intends to have upper compatibility to 1.9.2. > I think Ruby should in the future pay more attention to apply patches from the bottom up so that the User experiences more consistency when he switches to a new Ruby version. Our current goal is to migrate people to 1.9, not 1.8.8. Your logic, 1.8.8 is helpful for migration to 1.9, is still unclear and sticked on Oniguruma. Such logic, backporting new feature to 1.8 helps migration, was also done in 1.8.7. You know the result. You must show your logic is different from that of ours. Anyway your this sentense is translated as, we should merge pathces which introduces incompatibility to keep compatibility to 1.9. I think this is strange. > It is essentially what I believe is the problem of the micro-kernel. It is chopped up in to many pieces. And it gets worse if new releases are designed from the top-down instead of from the bottom up (meaning evolution through patches is a good thing). That is what Linus does well. He breaks down new features, he does not break old ones because a current user should not have a bad experience when he upgrades. If you buy a new car and everything is different from the old model (in a sense that the concept is completely different) then you will feel betrayed as a customer. Great products come with great consistency. Great products make you feel the change in a positive way. Really? Anyway, Language will change, must change. You know many rotten languages because of old core spces. Such languages will be replaced new one Ruby wants to replace old Ruby by ourself. > Please try not to break old habits, Methods and Concepts. We breaks old hapits to make better habits (in major bump). (2.0 is not such major bump because 1.9 is such one, in current schedule) -- NARUSE, Yui �