Don't fix it if it ain't broken
With new Linux kernel versions arriving on the scene every few months and new drivers and patches being released every day, it's easy to become addicted to patching and upgrades. After all, what's more exciting than telling your user community that you just found a new kernel patch and that you'll be taking the mail server down for the afternoon to install it? Some administrators justify their existence this way; everybody likes to be the hero.
A good system administrator carefully weighs needs and risks when planning kernel upgrades and patches. Sure, the new release may be the latest and greatest, but is it as stable as the current version? Could the upgrade or patch be delayed and installed with another group of patches at the end of the month? It's important to resist the temptation to let "keeping up with the joneses" (in this case, the kernel hacking community) dominate the best interests of your user community.
A good rule of thumb is to upgrade or apply patches only when the productivity gains you expect to obtain (usually measured in terms of reliability and performance) will exceed the effort and lost time required to perform the installation. If you're having trouble quantifying the specific gain, that's a good sign that the patch can wait for another day.