On Jan 29, 2008 5:56 PM, Ted Byers <r.ted.byers@xxxxxxxxxx> wrote: > > --- 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. I don't wanna spend a lot of time to keep updated the old (unmanteined) branches, but I will keep them working, for historical reasons and because in the future I could have the need to compare some output data .... Then is not a problem if they use obsolete tools. > 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. sure > > 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). indeed, may be one of them is less accurate, but is not wrong, this depends from your requirements which may change. If a new library (an algorithm of the new algorithm) promise to produce more accurate results, this isn't a sufficient reason to use it, this accuracy must go together with the "reliability" of the code (correct result for the whole representative set of input data), and sometime (not ever) the reliability of a code is not easy to be proved. In this case I would keep the old library until the tests procedures say that the code using new library is reliable. In critical environment the testing procedures are quite expensive, and you may need to keep different version of the same library (or tool) at least for the transitory period. > For many > calculations, there is only one correct answer. If for graphical interfaces for example, a change on the library may not produce a wrong or correct answer, but only a different result. In this case I will keep the library which fits better my needs, and I can decide to switch to this new library only on specific branches at a first time. When some functional changes are made to the library the problem is not if the result is wrong or correct, it's just different. In this case I would keep different versions of libraries for different branches because different behaviours may be desidered by different users. > 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). ok for the improved code, but as I said, the differences can be on functional behaviour, in order to keep unchanged specific functionality, may be needed to use an older version of a library on a branch, and a new version where functionality is to be provided different. This is a reason which could make troublesome the installation of library directly on the system. > > 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 I will not mantain all the version of gcc used since the first branch. I can keep the different versions of toolchains on a sandbox, this way the system tools can be upgraded without problems and independently, without the worry of potential incoming problems. I will use the new toolchains on all the mantained versions but only after an in depth testing. Meanwhile the validated version of toolchains (or whatever) will be used. > 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. > by Angelo > Cheers > > Ted > >
