There seems to be some confusion over the way we release CentOS, and the release cycle.
First, let's define what the upstream provider does.
They released RHEL-2.1 (originally RHAS-2.1), RHEL-3 and RHEL-4. Those are specific and unique releases. They have the following Maintenance Phases:
Phase 1: Full Support Start Date: General Availability
End Date: 2.5 Years from General Availability date
Description: During the Full Support phase, new hardware support will be provided at the discretion of the upstream provider via Updates, Additionally, all available and qualified errata will be applied to the Enterprise products via Updates (or as required for Security level errata.) ------ Phase 2: Deployment Start Date: 2.5 years from General Availability (end of Full Support)
End Date: 3 Years from General Availability date
Description: During the Deployment phase, all available and qualified security and bug fix errata will be applied to the Enterprise products via Updates. Security Errata will be released as necessary independent an Update. ------ Phase 3: Maintenance Start Date: 3 Years from General Availability (end of Deployment)
End Date: 4 Years from end of Deployment (7 years from General Availability)
Description: During the Maintenance phase, only Security errata and select mission critical bug fixes will be released for the Enterprise products. ------
Phase 1 and 2 products will get Enhancement updates (RHEA), Bugfix updates (RHBA), and Security updates (RHSA), usually released 2-4 times a year. The updates have numbers (ie., Update 1, Update 2, Update 3, etc.) Currently, RHEL 3 is at Update 5, RHEL 4 is at Update 1.
Phase 3 products will only get security updates, usually released individually. RHEL 2.1 is in this phase. There will probably be individual security updates released from this point forward on this distro.
http://www.redhat.com/security/updates/errata/
http://www.redhat.com/security/updates/
There is no RHEL-3.4 or RHEL-3.5 ... or RHEL-4.1. If you run up2date on RHEL, you get the updates when RedHat releases them.
There are separate ISOs for the different Updates ... but only one set (or tree) of updated RPMS for each distro (RHEL-2, RHEL-3, RHEL-4). If you install off any of the ISOs and then run up2date, you are at the latest update. For example, if you install off the RHEL-3 update 1 ISOs, then run up2date from RHN, you are at RHEL-3 update 5 when finished ... not RHEL-3 update 1 ... and all of this is RHEL 3.
----------------
How does this relate to CentOS releases.
First thing is this ... the releases are CentOS 2, CentOS 3, and CentOS 4.
Both CentOS 3.1 and CentOS 3.5 are CentOS 3 ... both CentOS 4.0 and CentOS 4.1 are CentOS 4.
So, unlike moving from Mandriva 10.1 to 10.2, moving from CentOS-3.1 to CentOS-3.5 is not changing to a new major OS release ... you are just doing exactly the same thing as the above upstream example. Moving from Update 1 to Update 5.
CentOS provides new ISOs (just like upstream) when an Update X is released.
Let me say it again ... moving from CentOS-4.0 to CentOS-4.1 is not changing to a new major release, it is just applying normally released updates ... except, at that point, there are new ISOs, with new hardware supported at install time.
So the CentOS release model is very much like the upstream one, if you run an update, you are at the latest versions for your release tree ... exactly like upstream.
--------------------- That being said, there are some who want to treat CentOS-3.1 and CentOS-3.5 as a separate release (or CentOS-4.0 and CentOS-4.1) ... and not part of the same tree. That is not how CentOS is maintained, but we have decided to enhance our vault to allow those people access to the individual trees.
If you look at http://vault.centos.org/ you will see that there are currently the following directories:
3.1, 3.1-final, 3.3, 3.3-final, 3.4, 3.4-final, and 4.0
In the case of the CentOS 3, the numbered releases are the starting point .. and the 3.x-final is the ending point tree for that version. In the case of CentOS 4, the 4.0 is the ending tree ... the beginning tree was just the os directory under the 4.0 tree.
There are no new security updates applied to those hives, and they are a snapshot of the tree at those points. Again, the tree here are _NOT_UPDATED_ any longer ... so don't use them and expect to have an up to date system. The up to date system is the latest trees that are always available via mirror.centos.org or the pblic mirrors.
The vault takes up a major amount of disc space, which will grow as we continue to release new trees and it is not replicated to public mirrors. It is also only available on one machine, so bandwidth and access may be much slower than the real CentOS trees.
My advice is that you should change your way of thinking so that you maintain your software the way the upstream provider and CentOS provide it, if at all possible. However, if you cannot do this, then the vault will provide limited access to the older trees.
Thanks, Johnny Hughes CentOS-4 lead developer
On Wed, Jun 22, 2005 at 06:42:41AM -0500, Johnny Hughes wrote:
Let me say it again ... moving from CentOS-4.0 to CentOS-4.1 is not changing to a new major release, it is just applying normally released updates ... except, at that point, there are new ISOs, with new hardware supported at install time.
So the CentOS release model is very much like the upstream one, if you run an update, you are at the latest versions for your release tree ... exactly like upstream.
This all makes perfect sense to me and sounds like a very reasonable scheme. In fact, it's one of the reasons I was suprised by the lack of 4.1 src.rpms. Which I know I keep harping about. :)
Matthew Miller wrote:
On Wed, Jun 22, 2005 at 06:42:41AM -0500, Johnny Hughes wrote:
Let me say it again ... moving from CentOS-4.0 to CentOS-4.1 is not changing to a new major release, it is just applying normally released updates ... except, at that point, there are new ISOs, with new hardware supported at install time.
So the CentOS release model is very much like the upstream one, if you run an update, you are at the latest versions for your release tree ... exactly like upstream.
This all makes perfect sense to me and sounds like a very reasonable scheme. In fact, it's one of the reasons I was suprised by the lack of 4.1 src.rpms. Which I know I keep harping about. :)
Thanks for this clarification Johnny. I also thought that a lot of people were confused about the releases...
It's simple, just update with yum or up2date :).
Did you put this page somewhere on the web so that we can send a link to confused newcomers?
Thanks,