I am not a programmer, but perhaps someone here has been one in a previous career, and can provide some insight.
The current method of accumulating several hundred sprs into a SP and beta testing it prior to release seems, to me, to be ineffecient.
What, in laymen's terms, prevents SW from handling updates in the following manner?
:Provide an update path similar to ( I really, really hate to use this as a standard ) windows. Once an issue has been addressed and corrected, an update can be released to address it specifically. If the user is not experiencing said issue, no need to install it. If the issue has been a major PITA for the user, he gets a much more timely fix (it sucks to see a fix, one you truely need, posted on the "fixed in the next sp" section of the website, only to have to wait 2 months or longer for it). In either case, if its determined that the "fix" caused more problems than it fixed, then the single update can be removed.
Once in a while, when a collection of single issue fixes have been released, and determined to be stable together, package them into a SP.
By allowing small code changes to address specific issues, when a regression occurs as a result of a fix, it would seem to be much easier to locate the cause. For example: user A has only two fixes installed, and user B has 5 installed. Only fix 21342_1 is shared between them, so is likely the cause ( simplified, but spread over hundreds/thousands of users, highly useful).
I ask this because 2005 sp4 fixed about 10 issues for me that I have been waiting for with baited breath, but a regression occured, which has forced me to install sp3 in a different location so that I can continue to work with files that the regression renders unuseable.