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

SaTriGuy wrote: > >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... > > That is a very scary bug! It makes me wonder whether I shouldn't always test for the number of rows updated, even when I am certain I am using a unique key which should only update one row (I think it would be a good idea, but would be difficult (a real pain in the butt) to implement on a large set of source code at this point.) > >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. > I think I can explain part of this mystery, especially after experiencing a situation with one of my company's customers. They felt as though they had already spent quite enough money on their version of Informix, and didn't want to have to spend more to upgrade. They had already paid for one of the highest levels of support (if not the highest), and wanted a fix. It may be shortsighted to ignore the possibility of introducing other bugs just to get a fix in for the current problem, but this is the reality of how people see software. They want it fixed and 90% of the time, if you give them a fix and they test it to see whether or not the fix fixed the problem at hand, they'll be happy, even though there may be unwanted (possibly worse) side effects.If Informix (and other software vendors), were more straightforward about fixing problems and offered upgrades at no (or insignificant) cost when major problems were found, and additionally informed everyone of the fact that the full QA process was not done on 'patches', then noone would want a patch, unless they needed it NOW and the next release was 2-3 months off (as they told us and our customer). > 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 th