On Wednesday 31 March 2010 23:05:00 Amarendra Godbole wrote: > I am having this discussion with a colleague, who wants to test the > application across various OS versions (Debian in this case). My > argument (supported by experience) is that one should re-test the > application only if the dependencies have had a major version change. > For eg., if app A depends on libc-x.y.z, and libfoo-a.b.c, ideally no > testing is required for all OS releases that have libc-x.*.* and > libfoo-a.*.* -- the same major version. > > The idea being - minor version bumps do not spring surprises, but > major version almost always do. App A is a "large enterprise app" > being discussed, and my idea is the optimize the QA cycles that the > team has to put in. > > Is my experience sound enough to say this, or are there any exceptions > to the norm? How does OpenBSD handle this situation? If I have to > release an app on OpenBSD-4.6 and -4.7, as long as I ensure that all > the dependencies of the app have the same major version across both > releases, it should run fine on both. > > Thanks. > > -Amarendra
I think its dangerous to automatically say that libfoo-a.b.c is going to be the same across OS's, as that assumes the compiler is the same. With the case of gcc, I'd be wary of that. As for minor bumps not being a worry, what if the part of the library that caused the bump is something that you really depend on? After having done testing of software/hardware in the pre-open source world, I've come to the conclusion that its cutting corners to make assumptions, and no matter how much of a pain in the ass it is, testing everything, at least sometimes, is the right thing to do. --STeve Andre'
