A Linux distribution is basically a collection of a ton of open source projects that make up the Operating System environment, with at its core the Linux kernel. Linux as a development project is about the Linux kernel specifically. There are then many (1000's) of random open source projects out there and a Linux distribution basically is an OS made up of, at its core, the kernel, and tons of those other projects packaged up. Now some packages are more critical than others, there's a small true core of packages that you will find in any Linux distribution, glibc (c library), gcc (compiler), filesystem utils, core utils, binutils, bash,... etc. A good guess would be about 150-200 packages that make up pretty much any more or less usable environment (yes you can do with far fewer but I 'm talking standard OS installs here...)
All these projects have their own development cycle, their own maintainers/developers, their own project plans, and their own dependencies. They just kind of all move along on their own pace, they're worked on by (usually) different people and so on. So how do these 1000's of packages get into Oracle Linux?
Oracle Linux is an exact replica of Red Hat Enterprise Linux (same packages, same source code, same versions,...)... so that's what we base our distribution on (similar to CentOS). Now Red Hat Enterprise Linux, in turn, uses the Fedora Linux distribution as its upstream baseline. Fedora is a community distribution (fedoraproject.org) that typically lives far ahead of what any one would install for a stable environment. It's a community driven, cutting edge Linux distribution. Fedora as a project has very frequent releases (like every 6 or so months). The fedora maintainers distribute maintainership of these 1000's of RPMs across a group of people and they gather newer versions of all these projects and build them for a given version of Fedora. They then stabilize this and release it. By stabilizing, I mean, they create packages, test out if all the dependencies work, if there's a build environment that's consistent and if there are bugs, and fix them of course.
So Fedora evolves rapidly (like every 6 months a new release) and as you go from Fedora 12 to 13 to 14 etc, you see the packages of gcc and glibc and all other stuff evolve version by version, gcc 3.2 to 3.3 to 4.0 to 4.4 etc. Depending on when the fedora project starts "freezing" the package list of the next version, that's what the various versions of those 1000's of packages will be based off of. The maintainers usually will, at some point of the release cycle, take the latest "stable" version of a given project (say gcc) and check that version into the Fedora tree. What happens here is that you typically see Fedora pick up the stable versions of projects pretty regularly. It helps shake out bugs, it reaches a large (end)-userbase and it helps the Linux community that wants to be on the cutting edge by doing a lot of the packaging for them and it helps the downstream use of Fedora because many of the base/generic obvious bugs and build issues have been resolved during the Fedora test, dev and release process.
Now, because Fedora moves so rapidly, newer versions of RHEL, and as such OL, obviously skip quite a few versions of Fedora. For instance, RHEL6 is based on Fedora 12/13, RHEL5 was based on Fedora Core6, etc... A new version of RHEL is released every few years. So Red Hat decides at a certain point in time to take a snapshot of a given Fedora release they deem stable enough at that point in time and then fork that internally into a separate repository, change the trademarks,logos, add some packages that might not be in Fedora, tests the components for a more commercial use, server use, (most of Fedora is desktop use) and then releases that as the next version of RHEL. And we then similarly follow with OL.
An important point to make is that within a given release cycle of RHEL or OL, the version of the packages typically doesn't change, at least not the major version (usually not 2 digit versions). For the lifetime of, say, OL5, the version of, say, glibc, will remain pretty static. It will include bugfixes over the lifetime of the distribution version, security fixes and sometimes minor important things that might get backported of a newer version (albeit rare) but that's it. So you have a relatively static vesion of an OS, it improves in stability, quality, security but it doens't improve much in terms of functionality. (Most of the enhancements would probably be in the kernel.).
This also means that a Linux distribution (RHEL, OL, CentOS,...) can skip package versions, if some external project goes from version 2.1 to 2.2 to 2.3 to 3.0 to 3.1 etc... over the lifecycle of OL5 and OL6, then OL5 might contain 2.1 and OL6 might contain 3.0 or 3.1. You won't see versions in between get picked up. Or, again, in some rare cases, if there's something really important that went into 2.3 that would be really relevant, it might have gotten backported to 2.1 as part of RHEL/OL. You cannot expect that OL5 would go from 2.1 to 2.2 to 3.0 for that given package. That's just not how things work. So if you expect major enhancements or features of some package that's newer than the version that's in the current distribution, you might (likely) have to wait until the next major release. Example : OL5 contains glibc 2.5, OL6 contains glibc 2.12. If there was something really, really important in glibc 2.8, that might have gotten backported into 2.5 and gotten into OL5, but it's unlikely. And OL5 will not start adding 2.6, or 2.7 or so into the distribution. And then the same cycle starts again with OL6, it contains glibc 2.12... but the current version of glibc upstream is 2.18, and Fedora 19 contains glibc 2.17. So the future version of RHEL7/OL7 might end up with 2.16 or 2.17, and it would have skipped over 2.13-2.15. One cannot expect that the commercial distributions backport features of future package versions into prior versions. That doesn't happen for OL, or for RHEL or CentOS or SLES etc.
What does happen, and it's important to point this out, is the fixing of CVE's/Security vulnerabilities or critical bugfixes. Example, let's say there is a security issue found in glibc 2.17 (upstream), and this is also relevant to glibc 2.5 found in RHEL5/OL5. We obviously will end up fixing that in 2.5 (backport the security fix) and in 2.12 (OL6)... So in terms of critical fixes and security vulnerabilities found in any version of a supported Linux distribution's package, those will be found in various versions, where they matter.
You can always track this by looking at the changelog of an RPM or look for a CVE number and you will see hits on different versions of an RPM in different versions of OL where it is relevant.
This is pretty normal stuff, new features go into new versions of a product, like new features go into new versions of the oracle database and we will fix problems and backport changes into older versions but you will not see new features for a new versions of the database pop up in an old version of the database. It's not rocket science. A Linux Distributions is a product based on tons of small subcomponents but in the end the major release is the overarching "feature" release.
The few exceptions (obviously there are exceptions :-) are : (1) it's possible that new packages for new products or components are introduced during the lifetime of the OS release, a new RPM can be introduced in 5.8 or 5.9 or so... (2) some of the backports of features I talked about earlier can introduce some enhancements, although rare (3) the Linux kernel is probably the most lively component in the OS where the rate of enhancements is the largest compared to anything else.
I hope this helps.