--0016363ba86839578e0462cf1b97 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Matz, I'm glad to see that you've entered this fray. I trust that you know me well enough to know, that while I have strong opinions, I have no ill-will, particularly to you or your language. On Fri, Feb 13, 2009 at 3:10 AM, Yukihiro Matsumoto <matz / ruby-lang.org>wrote: > Hi, > > > * Rails had problem from method name conflict. This was > unfortunate, caused by Rails' fragile monkey patching and our bad > for lack of thorough Rails test before 1.8.7. It is fixed now. > > * erb also had a bug in 1.8.7 initial release. It is fixed now. > > * two other problems are reported (SWIG and hash order), and as far > as I understand, they both contain bugs that haven't disclosed for > 1.8.6 by accident. > > I consider them minor and not being worse than previous releases. > Most of them are addressed already. Am I missing something? First, the next comment is directed to a subset of the Ruby community, which doesn't include you Matz, I know that Rails isn't liked by everyone in the Ruby community, but for better or worse, it's an important factor to the health of a significant portion of 'our' community. Those who don't use Rails or other large Ruby frameworks over time haven't experienced how we got to the point where these problems have been addressed. At this point, it's a little hard to recover the history, but, although Rails 2.2 is now compatible with Ruby 1.8.7 it has taken work, and new releases, from both the Ruby team and the Rails team. Rails users faced with upgrades, need to deal with the evolution of both Ruby and Rails. To a large extent Rails over the last year to 18 months has been even more volatile than Ruby. Porting a Rails app from Rails 1.2.x to Rails 2.0 (There was no Rails 1.3) was, as the change in major version number indicates a fairly significant jump. And Rails made changes in Rails 2.2 which, for applications doing certain complex things with ActiveRecord, VERY difficult to port. That's not Ruby's fault, it's just a fact of life. So there are quite a few Rails Apps, which need to stay on a version of Rails which is compatible with Ruby 1.8.6, but won't work with Ruby 1.8.7. |Back then nobody stepped up and said that if code working on 1.8.6 > |broke it is a bug so I just left it at that - the compatibility seemed > |to be not so great. > Of course, none of us is perfect, particularly without the benefit of hindsight. As a practitioner and advocate of agile techniques, I like to have a comprehensive test suite to expose compatibility issues when changes are made. Unfortunately in the case of a language like Ruby, it's impossible to have such a test suite, It would need to draw from a significant portion of the applications implemented in Ruby, and applications implemented on frameworks like Rails which are implemented on Ruby, etc. etc. Not really practical. If compatibility of 1.8.7 is really "not so great": > > * if it is fixable, we can fix. > > * if it is minor, we can upgrade 1.8.7 (or later) whenever we want, > as we did in the past. > > * if upgrading is not affordable for enterprisey people (yes, I > understand them; upgrading is costly even when incompatibility is > minor), I'm not sure who you are calling enterprisey people here. I know that you have no intent to disparage, but that term does carry a certain meaning of "the other guys" with some of the Rubyists, (and others) I run into. To me "enterprisey" means someone working in a large corporate enterprise, who is following strategies, architectures and standards, promulgated by enterprise vendors, like Microsoft, and IBM (to the extent IBM still has the influence to do this), probably because of edicts handed down from on high from the executives who play golf with sales reps from those vendors. I'm pretty sure that such "enterprisey" types make up a very small subset of the Ruby/Rails community. We don't have many sales reps who play golf with corporate executives. The vast majority of those using Rails are fairly small companies trying to leverage the almost unique advantages of Ruby and Rails to be able to quickly deploy into production, and incrementally improve core business applications. And the vast majority of Rails developers are either working for those small companies, or for a small Rails consultancy, or as independent freelance contractors. > they can keep using 1.8.6, which is maintained right now. > > Very true, I've got no argument with that, but it's important to understand that those who are using packaged distributions of Ruby from debian (including Ubuntu), RedHat, macports etc. have more trouble keeping 1.8.6 because normal system administration has a nasty tendency to replace 1.8.6 with 1.8.x where x > 6 because they don't differentiate versions with differences in teeny version numbers as backwards incompatible. While 1.8.7 is backwards compatible with 1.8.6 in theory. Whether or not it really is, depends on whether or not all of the ancillary ruby code on the particular system, like Rails, Gems, and local applications have been kept, or brought up to date. Savvy developers get around this by eschewing packaged versions and installing the components of the Rails stack, including Ruby, from source. But there are a lot of developers who trust the package maintainers, and run into these issues, and end up blaming Ruby. We could say "well that's their problem," if we don't care about the impact on the overall perception of Ruby. Perhaps that's the right attitude, but I'm not so sure. Would it have been better for those with these problems had Ruby 1.8.7 not included the changes from 1.9 which broke apps and frameworks? I think that the answer is clearly yes. But, for better or worse, it did, and we have to live with the consequences, that doesn't mean we need to be happy about it. As EngineYard raised their hands, the maintenance of 1.8.6 will be > kept, even after 1.8.8. If more evidence of great incompatibility is not shown, I will > consider it FUD, or FUD-like at most, even though I see no bad > intention from anyone. > I hope that this doesn't come across as FUD, or even FUD-like, I'm just trying to put a bit more context on why compatibility isn't a black or white thing, and the sources of real FUD. The real FUD doesn't come from discussions like this, it comes from those who either have run into these problems and blame Ruby. We have no control over what they say, we can only try to consider the effects of decisions on the broader community, within the bounds of our human lack of complete knowledge. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale --0016363ba86839578e0462cf1b97--