How configuration management differs from environment to environment, language to language. I can give a concrete example on how things are handled in deployments that I manage, where most of the software is written in python.
In the Python world, individual libraries are distributed as eggs, and list their dependcenies in the package metadata:
'pisa >= 3.0.29',
'reportlab >= 2.2',
'html5lib == 0.11.1',
'pyPdf == 1.12',
In the above example some package versions are left un-pinned, others specify a minimum, and the last two are pinned to exact versions only. The deployment tool then has the responsibility of picking versions where no exact versions have been specified to match the constraints set for this egg.
We use buildout to manage our deployments; it is a build system that uses python packages called recipes to construct software for us. It's configuration files easily let you include other configuration files letting you delegate responsibilities and specify different configurations for different deployment scenarios with ease.
Within buildout, we generally pin the exact versions for a release in a versions list:
versions = versions
setuptools = 0.6c11
PyRTF = 0.45
pisa = 3.0.33
development.cfg configuration could override specific versions, clear the pins for others, or pull in a whole new set of versions by also including the configuration for a large framework version upgrade. We often use a
staging.cfg to roll out test configurations to the staging server so the customer can sign off on test plans before changes are rolled out to production.
It helps tremendously here that large frameworks such as Plone publish version lists for the python packages that make up the framework; this let's you upgrade your application to use a new release of the framework, or just upgrade individual packages using a local override.
Finally, how we discover new package releases also depends on whom releases the packages; the Python Package index (PyPI) publishes an RSS feed of new packages, various projects have their own news channels, and for internal updates we use similar mechanisms.
It is important for us to keep our buildouts repeatable and predictable however, so we only upgrade packages when we actually need the changes in the newer versions and have tested the upgrade; but thanks to buildout configurations, setting up a CI server such as Jenkins for various setups (production, staging, project milestone, etc) is very easy. As long as your test suite has good test coverage, you could even automate pulling in new versions of packages from other teams within your organisation.