Reply to thread

Message: [QUOTE="Rick DeNatale, post: 4631146"] [Note: parts of this message were removed to make it a legal post.] 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 But if I understand this correctly, 1.8.6 code will also run on 1.8.7 and 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. 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. [/QUOTE]

Verification