Thank you very much, Johnny Hughes, Nikolaos Milas, (and others), for nice explanation & example.
If ALL new apps/libs starts to change their API without backward compatibility, then, definitely updating/upgrading core/base apps would cause domino effect, like you have pointed out. Various apps and libs are inter-dependent & inter-connected with each others.
But do all ALL apps, or, libs do really change ALL of their API set ? My understanding is, some new APIs are added for new features, and older same API gets more refined, and/or newer query or response parameters are added behind the old existing query/response.
Do not developers (when coding for newer version), anticipate ? ... that their app/lib will and may try to communicate with another older or another advanced (with extra query fields) app/lib, so based on that it need to provide answer (by adding extra new response/parameters after the older API standard/parameters) or take action ?!
I'm sure smart developers do really able to and do really code, so that their app/lib does not fail to receive & answer when interacting with an older app/lib or a newer app/lib.
If they(developers) purposefully does not honor backward compatibility handling in their app/lib, that is kind of like, forcing people to buy new computer/hardware for new Windows8.
Why apps/libs are getting bigger in src or in their binary size ? with what ! ?
-- Bright Star.
Received from Nikolaos Milas, on 2013-01-27 4:56 PM:
On 27/1/2013 5:11 μμ, Johnny Hughes wrote:
So upgrading one package can cause a domino effect that means you have either broken a bunch of packages or you have to rebuild a bunch of packages.
That is why you should *only* upgrade what is VITAL for your application(s), and in a carefully planned manner, as Johnny explains.
Building on the example I gave earlier, OpenLDAP Server, which IS important to be current in production due to critical bug (not only security) fixes, can be safely upgraded using LTB project RPMs (http://ltb-project.org/wiki/) which allows a current version WITHOUT affecting the rest of the system (by using alternate paths to install libs, executables etc.).
Any other Servers in need for a current version can be safely upgraded through a careful approach to make sure they don't break other things.
So, get to know your OS, your apps, your (S)RPMs; then plan, test on a non-production system, then plan deployment in production. For example, we *only* upgrade other critical apps like Postfix, Dovecot etc. when running as enterprise servers. There is no other option here; for example, Postfix as available in RHEL/CentOS 5, is no more supported by the Postfix developer. We have to build our own RPMs based on our particular requirements.
We enjoy the stability of CentOS because it allows us to only upgrade what is vital. We don't care about Gnome and other modernization(s). Our CentOS 5 enterprise servers do not even have Gnome installed.
Nick _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos