--- Angelo Leto <angleto@xxxxxxxxx> wrote: > > --- John Carter <john.carter@xxxxxxxxxx> wrote: > > > On Thu, 24 Jan 2008, Ted Byers wrote: > > > > > > > You're half right. If your program uses > library > > > X, > > > > and that library has a subtle bug in the > function > > > > you're using, then the result you get using a > > > > different library will be different. The fix > is > > > not > > > > to ensure that you use the same library all > the > > > time, > > > > but to ensure your test suite is sufficiently > well > > > > developed that you can detect such a bug, and > use > > > a > > > > different function (even if you have to write > it > > > > yourself) that routinely gives you provably > > > correct > > > > answers. > > > > > > > > So given how much reality sucks, one of > eminently > > > practical things you > > > can do is reduce the variance between what you > have > > > tested and what > > > you ship. > > > > > Right. So what is the problem with not upgrading > all > > your development machines to a new release of the > tool > > chain you're using until you have proven the new > > version of the toolchain won't break your code? > Or > > the reason may be the following: > you may want the old branches on your repository to > work with the old > libraries (note that changing a library could also > mean changing a > function's interfaces); > The versions of your code which have already been > released should not > be further modified and even when you need to > introduce small changes > (e.g. change an error message) it is not always a > good idea to use the > new library, so you may need > (at least for a given interval of time) to be able > to use the old > library on some branch. Furthermore the new library > may produce > different results not only because of some > unexpected error, but > simply because the library changes; sometime is > useful to keep both > the library in order to prepare the transition. > I find this line of reasoning wholly inadequate. It is one thing to maintain old branches of your code base. It is quite another to insist they continue to work with tools rendered obsolete. Yes, I know that changing a library can involve changes to functions' interfaces, but that is just another part of the cost of maintaining your tools. The bottom line is that if two versions of the same program produce different results, one of them is wrong (or in the case of tools based on environmental models, one is more wrong than the other, since there is no such thing as a "model" that is correct, only models that are adequate and reliable). For many calculations, there is only one correct answer. If one version produces the correct answer and the other produces something different, then the other is wrong a needs to be fixed. In other kinds of calculations, it is already known that the result produced can only be an estimate of the correct answer, and in most cases (such as numeric integration) there are ways to estimate the amount of error in the result. In such a case, when a genius in numeric methods produces a better algorithm for doing, say, numeric integration, then the new library may well produce a more accurate result than the old, but also good, code (you have to love people who can improve already decent code, rare as they are: I would not hesitate to pay a premium for their work). In such a case, one still has evidence that allows one to deduce the reason for any difference, and once that determination has been made, in my view professional ethics (focussed on how one treats clients) requires that the improved code be used in any and all variants of my own product (so even old branches that I may be maintaining for whatever reason will be improved with the use of the new code). If it is the case that the new version of the library is buggy, then don't use it until it has been fixed. If, instead, the new version of the library brings a bug in your existing codebase to light, then the old baseline code is wrong and needs to be fixed. If you have a user who is stuck using the old branch, for whatever reason, it is not a service to him to allow the bug to remain unfixed. To my mind, that means that all branches we choose to maintain must build correctly with whatever tools we are using in production at the time. It is, to me, a waste of resources to attempt to maintain a suite of versions of my development tools along with the suite of branches of my own code base. I will maintain as many branches of my own codebase as needed (and that number is typically very small, since most of these are only for development purposes and end ultimately being folding back into the trunk), but I will not maintain countless variants of the tool chain I use (unless, of course, a client is willing to pay a very high premium to do so, contrary to any advice I may give him). At any one time, then, I have only one version of a toolchain in use, and at most one more in an assessment phase before being deployed (and this only at the most opportune time based on detailed information about what changes are needed in the suite of branches that are being actively maintained). Even if I started a project using gcc 3.4.4, having upgraded to gcc 4.2.1, I am not going to maintain all versions of all branches of gcc since gcc 3.4.4, or even most of them. I am not even going to maintain 4.2.0, and any new release, from any branches I choose to maintain, will be guaranteed to build properly with 4.2.1, but the user is on his own if for whatever reason he wants to stick with gcc 4.2.0 or earlier. Similarly, when I decide to upgrade the version of gcc I am using, I won't be supporting earlier versions of it. If I am releasing source code, I will state in the release notes what toolchain was used for it. There will be nothing, though, that compells my users to upgrade either their tools or their copies of my code. It is up to them to make the same kinds of assessments I have made. If they come to a different conclusion, so be it. If one of them wants to maintain an old branch of code I have released, using older tools, they are welcome to do so, but I will not waste time on a toolchain I have set aside as obsolete in favour of a new version of those tools. I have, for example, both MS Visual Studio V6 and MS Visual Studio 2005 (commercial reasons require use of such tools in some circumstances). I am not going to waste time making my code build using MS VS v6 when I have MS VS 2005. Doing so would certainly result in wasted time and inferior code. Once I make the decision to upgrade my tools, I don't waste further time on the old ones. Cheers Ted
