James Carlson <james.d.carlson at Sun.COM> writes: > 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?
It actually seems even less bad than that. We're talking about the unit of delivery here, not the unit of change. The fact that what is delivered to the user is a package rather than a patch does not, and should not, imply that the end result differs. It's the difference between SUNWsomepkg + 4 patches, and a SUNWsomepkg already containing the results of those patches, I think, not anything more. -- Rich
