Stefan Teleman wrote: > > > Joseph Kowalski wrote: >> >> I'm tempted to derail this, not because it is wrong, but because the >> versioning and change control model is far from obvious. I fear a >> mail discussion to resolve this will be rather painful, but lets take >> a shot at it first. >> >> Before I even attempt that, I'd like to know the Linux model for >> this. Are these components contained in any >> of the major distros, and if so, what updates to these components do >> the distros make in their updates. >> To clarify, if this is in RedHat (I have no idea), what would they do >> between RHEL4u3 and RHEL4u4 and >> what would they do between RHEL4 and RHEL5 (now in late Beta). > > Both RedHat and SUSE (the ones i know) deliver PHP. > > They seem to follow the "Designer Model": every release of either > RedHat or SUSE starts off by delivering a _certain_ version of PHP5. > They tend to stick with it for as long as possible, and they patch it > internally. This is the reason why one ends up with versions like > php-5.2.0.3.1.2b (as an example), when the PHP Group has only released > PHP.5.2.0. Minor upgrades (i.e. RHEL3U3 to RHEL3U4) try to maintain > compatibility. Compatibility can, in fact, always be broken by > shifting the blame to the original author of software. > > Vendor sites which use RHEL or SUSE employ a rather large number of > people who keep very busy making sure that whatever > <insert-vendor-name-here> puts in their box, works. This is the > explanation for support contracts which advertise products such as > "Our Certified Linux RHEL3". It's been certified not to explode on > startup, and that's pretty much the extent of it. > > RHEL or SUSE customers which want different versions of PHP (or > anything else) build and support their own. > > For Apache, SUSE delivers mpm-prefork *or* mpm-worker -- one gets to > choose at installation time which one gets installed. But, they do not > coexist. Same for PHP: one can choose at installation time whether one > installs PHP4 or PHP5. > > Upgrades between Major Releases (i.e. RHEL3 to RHEL4) are > no-holds-barred: there is *no expectation whatsoever* of backwards > compatibility. Everything must be reinstalled, nothing is shared, and > rpm's of PHP (any version) for RHEL3 will not work on RHEL4. Nobody > expects them to be compatible. > > --Stefan Let me paraphrase, just to make sure I got this right. It's so much what I expected to hear, that I want to sure.
At a Major release of a distro, its a no hold barred approach. They probably just grab the newest. This would be the equivalent of a Major release of Solaris, but we don't do those. In an Update release of a distro, they apply only very minor, distro specific "patches". By the proposed Uncommitted levels, this seems pretty much what we would do in a Patch/Micro release. Do I have this right? - jek3 At an update release of a distro
