Problems with “open source” versioning?
July 17th, 2006
Billy Newport writes about problems with “open source” versioning:
“…component X uses V2.1 but a newer component thats supposed to run with X requires V3.0 and we can’t just put V3 on top of X because of support issues, X won’t retest and support V3.0 at this point in time so then you’re in a rock and a hard place.”
Is that an “open source” problem?
Take a random product. Let’s call it stack product L. Let this product L be based on product W. If there is a new APAR for product W it is rolled into a cumulative fix or fixpack. (Depending on the version of W the wording changes)
The problem that arises here is that L won’t retest and support the new cumulative fix of W and will only support the version it shipped with, even though the single APAR is not supported/available for product W because it has been rolled into a cumulative fix.
Doesn’t this look like the same problem? I think this is an issue of testing that is entirely inherent to software and can only be remedied by only coding to specific stable APIs so you don’t care which version a software is based on and I completely agree with Billy, but I want to raise awareness that this is not only an “open source” problem.
The following is the “solution” to the problem described above: You need to move to a later version of stack product L which supports product W at the cumulative fix level you want, but it is a complex and painful migration path that takes weeks of testing and causes downtime on the production system.
This is the real solution: The product manager and developers of stack product L are aware of this problem and everyone is working to solve it, but this will take time and I hope the open source developers will figure out the same thing as their interfaces mature.