On Wed, 27 Nov 2002, Gene C. wrote: >> I'm just surprised that so few people realize this, and sucker >> themselves into believing it. Personally, I can't wait until >> the distro ditches the idea of version numbered releases and goes >> with something more modern, but wether or not that ever happens >> is neither here nor there. > >Mike ... > >I do believe that there is something of value for the numeric >number of releases. In general, we know that modules built on >release (n-1).* will run on release n.* but that modules built >on n.* will not run on release (n-1).*. Modules? Kernel modules? We never give any guarantees like that. >Furthermore, there is generally more compatibily between the >"minor" releases of a "major" release than between major >releases. Depends on what you mean. Red Hat Linux 7.x built software should run fine without modification on RHL 8.0 for the most part. We provide compat environment just for that purpose. >While this information is useful to me and some others, I am not >sure that users in general appreciate this. Microsoft has >conditioned users to expect that anything that ran on old >versions of DOS or Windows will still run on the latest version. >I do not believe that this situation is completely true but I do >believe that this is the user expectation. That is definitely not true. Every new release of Microsoft OS's tosses out a pile of backward compatibility. And Microsoft doesn't hide this either. Also, in general that compatibility goes in one direction. You can install _some_, and perhaps even most Windows 95 software in Windows XP and it is likely to work to some degree or another. I don't know what Microsofts claims of official support are however. But you can't install Windows XP software in Windows 95 (unless the author of the software has also made it compatible with Windows 95, but that is orthagonal). I believe Microsoft only supports Windows ME and Windows 2000 and higher, both of which were released in the year 2000. Red Hat currently supports Red Hat Linux 6.2 and higher officially. 6.2 was released in 2000 as well. And RHL 7.x products support 6.x applications also. RHL 8.0 supports 7.x applications. I do not know wether or not we officially support 6.x apps in 8.0 or not, or if they "just might work, but are unsupported". In any case, it is all open source ultimately, and one could download older packages and install their own compat environment themselves and get things going if they needed to. We also include user mode linux (UML) in RHL 8.0, so theoretically you could install an older RHL release into UML. You could also alternatively install 6.2 or even 5.2 into a chroot environment. There are lots of possibilities. So I'd say that we support our OS releases as long or longer than Microsoft does, and we do so with more concern for quality and security, also keeping compatibility longer, either in an officially supported manner, or in a manner in which a user could if they wanted to, set up a compatibility environment easily enough. That is something impossible in Microsoft operating systems. Try to install Windows 95 in a chroot jail in Windows XP. >I am not sure what you mean by "something more modern". >Currently, they seem to have a "release" which they name >(Windows 2000, Windows XP, etc.) and then minor releases which >they name "service packages" (sp1, sp2, etc.) Since they do >release new function in services packages, this scheme could >work. Exactly. I've always hated the year based version naming of products, but I understand why it is done much more clearly now. Versioned commercial software generally never hits version 10. Either the vendor goes out of business first, or the product changes in some way and the version numbering cycle starts over again, or similar. Commercial software version numbered higher than 10 is rare, and most of the ones that have gotten that high have since switched to year based versioning. (Corel, Autodesk to name a few). Version numbers are really technical things that dont matter to users, and even sometimes confuse users. Why else would Microsoft have jumped Word from version 3 to version 6 (Wordperfect was at version 6 at the time), or Slackware have jumped from version 3 to version 7? End user perception and psychology. People perceive the version number to really mean something, possibly in comparison to a competing product. Year based version numbers removes a lot of this. So really, product support timelines, and product backward compatibility timelines are not too tied to version numbering schemes IMHO. Version numbering is useful for developers and more technically minded folk. For end users however I believe that marketing departments should take over product naming and generational differentiation. >On the up side, this approach could users something "easy" to >bring their system "up to date") and, assuming each "service >package" was rigerously put through a beta/QA test cycle, the >service pack would be "known" good. > >On the down side, Red Hat usually adds some new device support >in their releases. I can foresee a system which the major >release could not be install on new hardware because the device >support was in a service package. If Red Hat did use such a >major release/service package approach, I cann see them issuing >service packages AND integrated releases with the major rlease >integrated with a service package (too expensive and duplicative >of effort). You only forsee a problem because it is in a hypothetical situation that you've created that isn't based on any plans of Red Hat Inc. ;o) Solving that problem therefore wont help anyone. ;o) >However, I do believe it is worth some effort re-thinking how to >do distro packaging and release. That is an ever evolving process. Keep also in mind, that all of the above statements I've made, and any past or future messages in this thread are entirely my own personal opinion of things I have thought about. I have no idea whatsoever if Red Hat or anyone at Red Hat shares my opinion at all, So don't let my brainstorming lead you to believe anything is or will be changing any time soon in Red Hat Linux in this regard. I'm just brainstorming out loud. ;o) Take care, TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer XFree86 maintainer Red Hat Inc. _______________________________________________ xfree86-list mailing list xfree86-list@redhat.com https://listman.redhat.com/mailman/listinfo/xfree86-list IRC: #xfree86 on irc.redhat.com
