The "traditional model" for Linux distributions is not never "update" the versions of programs included with a given release version. Meaning, you do not update Gnome 2.2 to 2.4 in a release, Ubuntu 8.04 for example. The traditional model is to keep the 2.2 version of Gnome (any package, but using Gnome as an example here.) until the next release (Ubuntu 8.10) Most packages will back-port security fixes and enhancements to a FEW programs, if there is a definitely performance or feature increase, or if there are absolutely no other dependencies on the package (Let's say Firefox as an example)
If you want stable and non-changing choose one of the LTS (Long Term Support) releases, but you will NOT get the newer updated stuff in that package.
It would actually be a nightmare were distros to update the versions of other programs in a given package, since almost any "high level" program is going to have dependencies, Those dependencies would have to be updated/recompiled to work with the new program, however, it's possible that those dependencies are also dependencies for OTHER programs, so you wouldn't be able to update just one program, you would have to update all packages that depend on the dependencies of the other package you want to update. Because most distros depend on pre-compiled binaries, it would make maintaining the dependencies nearly impossible to deal with, hence the reason for frequent releases. Because a user expects (or had better expect) all installed packages to be upgraded to the release version at one time, these dependencies are all taken care of at one time, making the process pretty smooth (If the distro maintainers did their job correctly - I had several REALLY bad experiences with Mandrake (Now Mandriva) Linux in this respect, I won't touch it now.)
The only practical way to get around this problem is to compile all programs against the particular installed libraries on the system, and if a library dependency is updated, re-compile the affected programs against the new libraries. Because the programs are compiled directly against the libraries, and not distributed as pre-compiled programs/libraries, individual packages can be upgraded and not break other programs.
This is the method that Gentoo Linux uses, hence there are no "release cycles" to deal with. It also allows all the programs to be compiled with all the features/capabilities of the particular CPU you are running. Ubuntu Desktop kernel is compiled against an Intel 586 architecture, so if you have a Core2 Duo, or AMD Athlon, the programs are not capable of taking advantage of the additional features and enhancements in these CPUs. Ubuntu Server kernel is compiled against the features found in an Intel 686 CPU. Again, not taking advantage of the newer features. This allows the Desktop edition to "run" on just about any computer from 586 up, and the server edition to "run" on any 686 or above, but neither will run OPTIMIZED for any newer CPU unless you manually re-compile the Kernel and programs.
Because Gentoo compiles each program (after the initial install) each program you are running is optimized for the CPU you specify in your configuration file. If you tell it march=nocona in the make.conf file, the programs and kernel will all be compiled optimized for a Core2 system, march=amd64 will optimize for an AMD64 processor. This *does* mean that you can NOT take your sytem and move it from an AMD architecture to and INTEL architecture PC without recompiling your entire system (expect that to take a day or two) but let's face it, not too many people do this. I did move my system from AMD64 to a CORE2 Duo system without any great deal of difficulty by simply recompiling the kernel for the CORE2, then rebooting and selecting the CORE2 compiled kernel. There were a bunch of program errors when the system came up, but I was able to re-compile the entire system (with a single command) and once the system was recompiled for the Core2 everything was fine.
The pre-compiled binary distribution of most distros is faster to install, faster to update, a little easier to maintain, but the systems run a little slower than a fully-optimized system, and you also have the time you spend doing "version upgrades from 8.04 to 8.10 to 9.04 etc.
It is Linux's fast release cycle that allows it to stay ahead of older "Traditional" release-cycle software such as Microsoft & Apple. Were the release cycles to become less frequent, Linux would loose some of it's cutting-edge advantages very quickly.