New updates appear about every 6 months and smaller patch sets come out even more often. What is the general practice for applying these updates?

In the Microsoft world, most of the patch sets are security flaw updates so they are applied rapidly but there is always a concern about the impact. Patches to application software have to go through a level of testing.

What is your distribution?

Ubuntu and derivatives follow this pattern:
Generally upgrades coming from the official distributions sources are well tested and bug fixes etc. Therefore it's recommended to install them. And every 6 months a new distributions is released which you may or may not upgrade. But that release has new versions of software and packages including new features etc.

It'll make more sense if we know your distribution.

If he uses slackware there won't be any answer.

if you use slackware: " Only Pat knows when the new version has to be released. "

Hi,

we use RHEL at most customer sites, managed by my team.

Upgrade will only be installed when new features are required (glibc or some like this). This means if there is no requirement for upgrading to newer release (eg. RHEL 4 to 5) we will only upgrade at end of lifetime support of distribution vendor.

Patches will be installed as fast as possible (some testing has to be done before deploying to the customer site) to prevent from security issues.

A statement which, no offence, suggests you are somewhat naive in things Linux. Not every Linux distibution releases a new version every 6 months. Ubuntu and Fedora do. Debian, Gentoo, openSUSE and more, do not.

In an Enterprise environment what is important is not how often new versions of a distro are released but how long any given release is supported for. You (most probably) don't want to end up in the position of running a distribution which is no longer supported by it's vendor as then you will not be getting security updates. But at the same time you want to be in control of when you update.You want to be able to update according a schedule you decided on, not a schedule dictated by the ending of support for the distro you are using.

On free distros (E.g. Ubuntu, Fedora)the supported life can be as short as little more than a year or 18 months. Ubuntu do Long Term Support releases though which are supported for three years. The last such release was 8.04 release in April 2008.

There are also a couple of what are called Enterprise distros. SUSE Linux Enterprise (SLE) is one, the other RedHat Enterprise Linux (RHEL). New versions come out only every few years and are supported for around five years. For example SLE 10 came out in early 2006. Whilst there have been a couple of service pack releases there have been no major changes as you would see between new versions of a distro. (I.e. library versions have stayed much the same and the only two significant updates to software that I can think of are Firefox which was updatged from 1.5 to 2 and is now stuck there, and Open Office which has been updated to version 3). The next version of SLE, 11 is due for release sometime in the next few months, three years after version 10.

Where I work we're using SLE. We use it partly because management like to use something that has been paid for and comes with some level of support, partly because it's sold by Novell and we already have some Novell infrastructure, and partly because it has a life cycle long enough that we will not find ourselves in the position of having to update every 12 months as we would if we went with something like Ubuntu (LTS releases excluded) or Fedora.

As for how we handle updates, well, we've been running SLE 10 for nearly two years now and will probably update to 11 over the summer as summer is the window in which we can re-install all the machines. Or we may wait until next summer as that will still be within the SLE 10 support period. We'll updated to SLE 11 before it goes end of life and because the life span is 5 years we have a nice amount of leeway.

As for the how we handle the steady trickle of security updates and such that come along, we use two sets of repositories. Updates are downloaded automatically every 24 hours and put in to a set of repositories which my own machine and a few others use. This means the updates are installed on those machines within a day of release. After a week the updates are automatically copied in to our live repositories which all the machines look at. We do no actual specific testing of updates but we do have that week to see if any updates break or cause problems on our own machines before we let them get to everyone else's machines. If there is a problem with an update we can disable the copying of updates to the live repos until we sort it out. We have never had to do that and there's been only one update that we've seen a problem with and that was not anything that affected functionality.