Les Mikesell <lesmikesell at gmail.com> wrote: > I'll mostly agree, but RH9 was never called 9.0. Nor was Fedora Core 1, which was originally named Red Hat Linux 10. Red Hat dropped the revision model for various reasons. I still disagree with that decision to this day, because the 2-2-2 -> 6-6-6 lineage is still there, and it must be for RHEL to maintain quality. > There were differences in how extreme the changes were. > I'm not sure you can make any kind of judgement about how > big an improvement each was over the last much less a > prediction about whether the next version will be. Since when could you make a prediction on Red Hat Linux? What many people considered to be the packages in Rawhide, which was basically already headed into Beta, for Red Hat Linux 8.0 was retroverted to Red Hat Linux 7.3 in a matter of weeks, going back to GCC 2.96/3, GLibC 2.2, etc... from GCC 3.1/3.1.9x, GLibC 2.2.9x, etc... that had been in Rawhide until that time. In fact, Red Hat had a policy of _never_ announcing products in advance, and that last to this day. You have to take each release on the merits of what is included. That's what I do, and I call them how I see the GCC, GLibC, kernel and other core components. > If you base your logic on the major version numbers of the > included packages you can make some kind of point here, but > in practice your individual problems are going to be shaken > out in some obscure minor-rev update or a backport of > something fixed upstream - and these can introduce new > problems too. Was this any different in Red Hat Linux before? And that includes Red Hat Linux 7.x, 6.x and even 5.x? > I don't disagree with your observation. I just think it > overgeneralizes the issue and it makes more sense to look > back at the number of updates in the repository at the end > of a cycle to judge how much was broken in the release than > to assume that an application version-level jump is going to > cause more problems than it solves in the release that > introduces it. The reality is that anytime Red Hat adopts major, core component changes, you have to deal with: A) Their immaturity, and B) The fact that a lot of existing code might break That remains unchanged today, including the fact that Red Hat has releases where they changes lots of things -- introducing that immaturity and breaking compatibility -- and then following-up with one or two more that do not change much. They just haven't given you any warning of this since Red Hat Linux 9. -- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith at ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers)