Stefan Teleman wrote: > > > Joseph Kowalski wrote: > >> 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 > > Here's a concrete example: > > I used to have SUSE 10.0 on one of my laptops. It had KDE 3.4.2. I > then upgraded to SUSE 10.2. To me, this seems like a minor upgrade. > Although YaST2 identified it as an upgrade, this was, in fact, not an > upgrade, it was a full overwrite. Nothing from SUSE 10.0 was > preserved, KDE was "upgraded" (overwritten) to "3.5.5 release 45.2" > (which is not an official KDE release, it's KDE 3.5.5 + SUSE). > > Half of the KDE applications delivered with SUSE 10.0 and KDE 3.4.2 > disappeared in SUSE 10.2 and KDE 3.5.5, although i requested to > install the "Full KDE". I tried to install a KDE (3.4.2) rpm from SUSE > 10.0. I had to use --force --nodeps to get it through. > > It did not work, it crashed on startup. > > I seems that in the Linux world, any number change is a Major Upgrade. > > --Stefan > Your concrete example only shows that SuSE is out of control. After using SuSE 8, 9 and 10 to test some Java installation changes, it doesn't surprise me. (I know this is open - no offense to SuSE lovers.)
What I'm getting at is that the community providing this and the community consuming it (linux in general), seem to have no expectation of multiple, co-resident releases or interface stability. Going back to the earlier cases dealing with FOSS, this makes this stack either inappropriate for inclusion in Solaris or if included, only included as Volatile. The other option, would be to included it as Uncommitted, and only update it (from the community) at Minor release points. We could do point upgrades (read forks) if needed for truly serious problems, much as you asserted the distros do. This would probably be viable if we still did Minor releases at roughly the same frequency as the Linux distros, but I guess we don't do that anymore. (Insert long digression about no Minor release being scheduled here.) In any case, I don't see that keeping multiple versions of this stack on Solaris makes any sense. We could build versions into the paths, doing the moral equivalent of static linking (as seems to be proposed), but it seems this would be counter to the assertions just made about path compatibility being important when importing from the FOSS world. I don't believe having a "latest" link helps here either. If they bind against something with "latest" in the path, it gets to use a whole new set of objects when the link value changes. - jek3
