Re: WARNING: Say "NO" to patched versions!

>At this years Informix Worldwide User Conference I learned that patched >versions of engines do not go through the same quality control procedure >that normal, scheduled, releases do. I formed the opinion that "patched" >versions were something I wanted to avoid at all costs. > >Today I learn that a "patched" version has been installed at one of our >client's site. > >The new version *does* fix the bug it was supposed to, but introduces another >cool one in its place: > >"UPDATE ... WHERE CURRENT OF" disregards the "CURRENT OF" clause. >It just UPDATEs every row in the table... > >Also at the conference I heard somebody request that Informix make their >test suite public, so users could check new releases themselves. At the time >the request didn't seem too important to me, but all of a sudden it strikes >me as being a fabulous idea. > >I think either Informix should abandon the creation of these ad-hoc, >untested, >"patch" releases, or at least make the test suite public so *we* can test >them. > >Thanks for listening > >Kerry S > No, thank you Kerry for bringing this issue up. For several years whenever a customer has run into a problem, it has been Informix's position to try to get the customer on a commercial release that addresses that problem. The choice of a patch has always been the "last choice" candidate. The commercial releases go through a rather extensive test suite that takes about two weeks to complete, several gigs of disk space, at lease a four processor system, etc. The patch is based on one of the commercial releases and is only unit tested for the specific bug. The QA test suite is HUGE and is getting larger day by day. Every time a new bug is encountered, it causes the test suite to be modified. Also, we have engineers doing nothing but createing new tests. I'm still completly baffeled when a customer insists on staying on an older release, say 7.12, and prefersl patches instead of migrating to a more current release, with the patch in place, which has gone through the complete QA test suite. But it still happens ... Quite a mystery. Since the start of this year, we have introduced the concept of releasing an interim release every month containing the major/coded bugs that have been encountered during that month. This is restricted to the "current" release (sorry 7.1x). So even though 7.23.UC1 has only been out for about 6 months, we are just about to release 7.23.UC6. The number after the UC (Unix Commercial) is the interim number. These interims do go through the test suite. So, the need for the "patched versions" (i.e. UC1X2) has greatly diminished. Is simply makes more logical sense to use a fully tested release. Since 7.24 is just about to be released, the 7.23.UC6 interim will probably be the last of the 7.23 product line. The 7.24 product is basically a stability release for the 7.2 product line. Yes, there are some minor enhancements added, but these are basically "finishing touches" to things that were already in 7.23, but not yet documented. So 7.24.UC1 is basically a stability release for 7.23. The major difference between the UC1 release of a product is that the UC1 release is actually done by product developement. Patches go into that release are entered by R&D and about every six months or so, the code goes into a freeze and the test cycle begins. Patches that go into the interims are actually coded into the "current R&D" product, and then are back ported to the interims. Thus the patches that are in 7.23.UC6 were already coded in the 7.24 product. This may sound like we might be putting in patches that have not been QA'ed, since the 7.24 product is currently just about to be released, but that is not quite right because the "current" product is built every night and then a QA test suite is run against it. Also, the Interim itself will go into a QA test suite as well. So that means that the Interim version has actually gone through several QA test suites by the time it's done. Yes, there are still some reasons for the UC-X-- versions (patches), but not nearly as many as before. It's possible that an engineer in support has discovered and patched the cause of the bug. However, that solution is rarely the "official" solution. Since the code that goes into the interims must be coded in the "current build", the origional solution can change drastically as R&D considers for the most generalized version of the patch. So this means that for some patches that are perfectly OK, it can be several months before the "official" patch makes it into the main code line. Also, it is posible that the "official" version of the patch did not get coded in time for the code freeze of the interim. That means that it could be up to 6 weeks before the interim that will contain that patch will make it to a commercial releasable statie. So again, a patch might be necessary. Again --- Thanks for the comment. Believe me, you are saying exactly what Informix has been trying to say for the past several years. Madison Pruet