Peter Tribble writes: > In an upgrade, you go from version X to version Y and all changes > 1 to N to the code are included, whether you want them or not. In > a patch, you stay at version X, and only some subset of the changes > are included. Support matrices for commercial software essentially > insist on this model. My own (painful) experience of managing Linux > distributions where upgrading components was the way to get fixes > was that it regularly broke our applications.
Mine too, but how much of that is due to a lack of architecture in Linux (not necessarily paying attention to stability levels and release bindings), and how much is due to the delivery mechanism itself? I suspect that if Linux had the equivalent of Solaris patches, you'd get just as much brokenness when installing them. Software is like a sewer. What you get out depends on what you put in. > Well, yes, I didn't mean literally one bugfix per patch. But the general > principle is to minimize the changes you need to make the system in > order to fix one specific issue. The dramatic downside to that is that (fairly likely) nobody has ever tested exactly the combination of changes you've applied to your system. You're flying blind. If it works, it's at least partly due to luck and paying careful attention to what gets backported, not due to inherent goodness in patches. To get the equivalent in the new order of things, advocate for smaller consolidations. Smaller consolidations mean more discrete sets of changes that can be chosen. The trade-off is that in order to create smaller consolidations in a safe way, we need to either cut up the big ones along lines that don't involve private interfaces (quite possible today with ON), and/or we need to make some of those private interfaces more stable -- and thus stop "innovating" in certain areas. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
