On 07/23/2011 06:07 AM, Karsten Hilbert wrote: > > On Fri, Jul 22, 2011 at 04:44:40PM -0400, Laurent Parenteau wrote: > > > > Or do you really prefer something like postgresql? What about > > > bugfixes? If there is a version 1.2.003 in the repository, do you > > > provide bugfixes for such an old version? > > Yes, we would like it if it would be possible to install older versions > > from the repository. > > As for bugfixes, we don't have "patch" releases, as you often see in > > other software. We only have full releases. When there's an important > > issue that requires a fix fast, we simply spin a new release (which will > > have a letter suffix, like V5.4-002B) that will, among other things, > > include the fix. So once V5.4-003 will be out, there should never be a > > V5.4-002C. > > That, by extension, means that your nascent, next-release > code (say, v5.4-004-to-be) will at least be as stable, > tested, and trustworthy as the already released, tested, > field-proven V5.4-003 such that you can safely spin > V5.4-003A from V5.4-004-to-be plus the "B" bug fix ? > > In other words - you never introduce regressions during > development ? > > Or am I misunderstanding ? > [KSB] Karsten, you are not misunderstanding. I don't say that we never introduce regressions in GT.M, but they are very rare. I don't claim bug free software - not in my lifetime, certainly - but I do say that regressions are very rare. Here is why.
GT.M has an extensive automated testing infrastructure and an extensive set of automated test cases that runs weekly. We normally kick it off every Friday afternoon on the latest code base in version control. The test cases include things like simulated system crashes and recovery. The tests also randomly vary parameters, so that over time even unlikely combinations of parameters are tested. The fastest machines finish over the weekend; the slowest machines finish the following Thursday. Every time we create an enhancement or fix a bug, we also write automated test cases for the change. In the case of bugs, the test cases show the presence or absence of the bug. The software validates the test cases and the test cases validate the software. The software goes into version control and becomes a permanent part of the code base. The test cases go into version control and become a permanent part of the testing infrastructure. We invest as many person hours on developing automated regression test cases as we do developing software. Yes, there are a few things that we do not test every week, and which are tested once in a release cycle. There is a class of automated tests that are called "manually started test cases". These are tests that take too much manual interaction, too much system resources, or too much time (for example on 64-bit platforms we have a shared library stress test that uses something like 175000 source code modules to create more than 4GB worth of shared libraries that a process links in order to test addressability). There is another class of "manual tests" which just require human interaction. But these are few in number and whenever we add a test to one of these categories, we first convince ourselves that it is not possible to create an equivalent automated test. We are also fastidious about upward compatibility. Over the last sixteen plus years that I have managed GT.M, there have been perhaps a half dozen cases when we did not have strict upward compatibility. When we do that, it is only because there is a very good reason, and we highlight it in the release notes. For the most part, our user base expects to be able to upgrade from an older version of GT.M to a newer version, and have existing application code and scripting just work. I hope this helps. Regards -- Bhaskar -- GT.M - Rock solid. Lightning fast. Secure. No compromises. _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________
