New page: Libraries evolve, produce new and new versions and from time to time, every system relying on them is required or forced to upgrade to new library version. The problem with almost every up...
New page
Libraries evolve, produce new and new versions and from time to time, every system relying on them is required or forced to upgrade to new library version. The problem with almost every upgrade however is that it delivers not only so much needed bugfixes and new features, but often also causes a lot of regressions. As a result many software users exhibit so called ''fear of upgrades''. Is there a way to guarantee that a library upgrade can cause no harm to existing system?
== Is there a tool to verify upgradability? ==
Few thoughts from discussion on [http://lambda-the-ultimate.org/node/2950 Lambda-the-ultimate]:
Right now the [[NetBeans]] project relies on programmer's declaration that a new version of a library is compatible, however if there was a bit of support from tools, the absolute compatibility could even be verified automatically.
It is not impossible to verify that all code which can be executed by usage of the old API remains unchanged, while the new code additions can only be invoked with at least one use of the new API. If this check passes, then it implies 100% backward compatibility and allows the new version of the library to be upgraded in an existing system without any fears.
This is really draconical and probably only suitable for patch releases. At least this is my experience from creating a desktop framework. However, it all depends on the need of quality. If a library was used in heart of plane control system, I would rather accept this check for all releases.
Of course, this works only if you control all the calls into the library and you can guarantee that nobody will call the new API methods. But if the only change in your whole system is just the library itself (and it passes the "no change to previously existing code" test), then there is nobody who could call the new API methods. Your whole system knows nothing about it, as it was compiled against version of the library which did not have it. So the upgrade is safe, the behaviour has to stay the same.
Now imagine, that you change code of your system to call the new setter. Well, invariants can no longer hold, and things can break, but I'd say that it is OK - programmers are used to destabilize the system when they change their source code ;-)
Also notice that if you upgrade more libraries, and all of them pass the "no change to previously existing code" test, the whole set of them will pass the test as well. This property of the libraries seems to be transitive. Which is good, I still see it as a possible, yet draconian test for safe [[Upgradability]].
--[[User:JaroslavTulach|JaroslavTulach]] 09:26, 30 September 2008 (UTC)
== Is there a tool to verify upgradability? ==
Few thoughts from discussion on [http://lambda-the-ultimate.org/node/2950 Lambda-the-ultimate]:
Right now the [[NetBeans]] project relies on programmer's declaration that a new version of a library is compatible, however if there was a bit of support from tools, the absolute compatibility could even be verified automatically.
It is not impossible to verify that all code which can be executed by usage of the old API remains unchanged, while the new code additions can only be invoked with at least one use of the new API. If this check passes, then it implies 100% backward compatibility and allows the new version of the library to be upgraded in an existing system without any fears.
This is really draconical and probably only suitable for patch releases. At least this is my experience from creating a desktop framework. However, it all depends on the need of quality. If a library was used in heart of plane control system, I would rather accept this check for all releases.
Of course, this works only if you control all the calls into the library and you can guarantee that nobody will call the new API methods. But if the only change in your whole system is just the library itself (and it passes the "no change to previously existing code" test), then there is nobody who could call the new API methods. Your whole system knows nothing about it, as it was compiled against version of the library which did not have it. So the upgrade is safe, the behaviour has to stay the same.
Now imagine, that you change code of your system to call the new setter. Well, invariants can no longer hold, and things can break, but I'd say that it is OK - programmers are used to destabilize the system when they change their source code ;-)
Also notice that if you upgrade more libraries, and all of them pass the "no change to previously existing code" test, the whole set of them will pass the test as well. This property of the libraries seems to be transitive. Which is good, I still see it as a possible, yet draconian test for safe [[Upgradability]].
--[[User:JaroslavTulach|JaroslavTulach]] 09:26, 30 September 2008 (UTC)