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@xxxxxxxxxx > http://lists.centos.org/mailman/listinfo/centos >
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
