From: Rick DeNatale Date: 2009-02-12T06:51:55+09:00 Subject: Re: If you are unhappy with the direction of Ruby 1.8.7+, respond --0016364583785e16ba0462aba1bf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Feb 11, 2009 at 4:13 PM, Robert Klemme wrote: > On 11.02.2009 18:27, James Gray wrote: > >> On Feb 11, 2009, at 11:10 AM, Gregory Brown wrote: >> >> I am setting up two threads in the hopes that we can see names >>> attached to opinions about the decision to break backwards >>> compatibility between Ruby 1.8.6 and Ruby 1.8.7+ >>> This one is for those who wish that Ruby 1.8 would go *back* to being >>> 1.8.6 compatible in Ruby 1.8.8. >>> >> >> I'm bothered by the new versioning scheme. >> >> The new releases involve big changes and even if they are fully backwards >> compatible about what they will run, they are still creating pretty big >> compatibility gaps. Code using any of the new 1.8.7 features won't run on >> 1.8.6 and lower. >> > > Well, but this is usual, isn't it? If you want exact 1.8.6 then take > 1.8.6. Or do you see changes in the third number as sole bug fix changes? That's the industry practice, a minor version number change normally means that there should be no or very little impact on the installed base of 'legacy' code. It sounds as if 1.8.8 intends to take this farther, so code written to > that won't work in the different 1.8.7 branch or the earlier 1.8.6 and > lower stuff. > But if I understand this correctly, 1.8.6 code will also run on 1.8.7 and > later. I must say that I'm not entirely up to date with what NOW works on 1.8.7, the stuff which used to break, e.g. rails and many gems has been catching up to the changes, but that is cold comfort for those who are faced with a broken deployment and either have to back-level dependencies, or go through a sometimes painful process of migrating a large application from the version of, say rails, they were using to the new one which runs on 1.8.7. It's not so much of a problem for folks writing standalone code, or code with a small set of dependencies, but it has, and I suspect it continues to have, a large impact on a lot of folks trying to maintain their bread and butter. > > Thus I feel we now have three different versions of Ruby 1.8 on the >> table (counting the not yet released 1.8.8). >> > > That seems to be the case. Maybe 1.8.7 should really have been 1.9.0 but > that version is taken already... IMHO the changes in 1.9 are big enough to > warrant a 2.x but I guess Matz et al. have put quite a bit of thought into > the version numbers - so maybe we should hear that before we make any > judgments about what fits in a release and what not. > As I remember it, Matz didn't want to have a version number like 1.8.10, and since there was danger of 'running out' the version numbering scheme was changed to make 1.9.0 the 'unstable' development release, and use a teeny number greater than or equal to 1 to indicate stability. This was OK as it stood, but then 1.8.7 came along and introduced incompatible changes backported from 1.9.0. Regardless of the percentage of gems and frameworks which have been updated to work with 1.8.7. I still maintain that the backporting in 1.8.7 was a bad idea, and pushing it further would compound the problem. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale --0016364583785e16ba0462aba1bf--