Thinking out loud...
First, I totally agree with your comments regarding "classic" product numbering.
Is there a solution? I don't think so. A measure that would be helpful would be an advisory as to WHO should perform an upgrade and WHAT they may expect. Even with ad hoc patches, a maintence release should not cause problems. On the other hand, all these updates and patches are the result of a service-oriented, technology-driven approach from ISC that has served us well for years.
I would submit that the latter is being hindered by the current deployment mechanism. It is too coarse-grained; the "Cach� kit" is the basic unit of update, and then there are the ad-hocs, but these are (to my best knowledge) not widely publicized and do not follow standard installation procedures. Then again, maybe they never could.
What if we had the Cach� Install System? This has been asked for time and again in this newsgroup. It is not precisely straightforward to push updates to customers. By building this as part of its own deployment process ISC could solve two issues at once.
Now, many updates are done to Cach�'s own platform-specific executables and libraries, but many more take place at the Cach� application level. If ISC were to create a "universal installer" of sorts, these updates could be provided individually as they became available (think each entry from a kit's release notes)
There could be a Cach� utility to handle a database of installed updates which could be exported to an (encrypted?) file. You would upload this file to a Web site and it would show you what's new for your configuration. You would choose that which is important to you, test it and push it to production. As John says, the basic premise of these patches is that they should not be disruptive.
Naturally, this brings at least two major problems for ISC. The first is that the number of such updates would be non-trivial, but it seems their internal processes can handle that well. The other main issue is support; it could be nightmarish to maintain the exact same configuration a particular customer has. Then again, I don't know how they handle this with ad hocs; and using the update database idea, they could conceivably have an automated way of loading and unloading updates to reproduce a particular configuration from the update database file.
My bottom line: this would give everyone the choice to update as quickly or as slowly as reasonably practicable. Get updates as soon as they are individually released, or wait till the next point release if you prefer.
There are lots of issues with this - QA and testing comes to mind. But like I said, just thinking out loud...
Ram�n
