[ sorry for the late reply, catching up with e-mail after holiday ] On Sat, 8 Sep 2007, Karanbir Singh wrote: > the issue here is that if VAR Mr.$X only supports a product on 5.3.1 > and CentOS does not provide that, there is a problem. The landscape > is littered with people / vendors / support people only recommending > people stick within a specific release Update version IMHO, this comes specifically from the fact that upstream doesn't only provide fixes (including security ones) but also functional improvements, such that ISVs fear that future updates can influence the functionality of their products. So upstream has decided to make it clear which updates are considered "safe" and which could potentially bring incompatibilities. F.e. for a scientific program that only does computation and doesn't use any graphical libraries, a security fix for 'kdelibs' coming in 5.0.2 would be sure to not break the program which worked on 5.0.0 and 5.0.1, therefore the ISV could certify the program for the whole 5.0.x series; OTOH, a new kernel coming in 5.1.0 could potentially change some memory map layout (not important for the great majority of software out there) and break the program (which was badly written in the first place, but the customer doesn't know this ;-)), therefore the specific software version would loose its certification for 5.1.x. So the way I interpret this: there are not going to be n+1 different distributions released at n-th update step (5.0.2, 5.1.1 and 5.2.0 at update step 2, following 5.0.1 and 5.1.0 at update step 1), but n+1 different distributions in total after n-th step (5.0.2 will replace 5.0.1 which replaced 5.0.0, 5.1.1 will replace 5.1.0, 5.2.0 is the new kid on the block). It's a very similar way of thinking now of versions 3 and 4 with updates, but without the potential breakage associated with those updates. As such, I believe that there's not going to be any need of maintaining a CentOS 5.0.1 forever, but this is going to be replaced by 5.0.2, just as now 3.8 is replaced by 3.9; it's going to be needed however to keep 5.0.x and 5.1.y (and so on) as separate distributions just as now 3 and 4 are kept. But between 5.0.x and 5.1.y there is still a large chance of identical packages (as upstream doesn't like to rebuild packages that work even if, or especially if, the compiler set changes) which should also translate into identical CentOS packages. Those could very well be handled by hard links, just like today. Some packages will certainly drift over time and will therefore require extra space, but I don't believe that it's going to be such an explosive growth as expressed here earlier. And there's going to be needed a 5.0 soft link pointing to the latest 5.0.x release, a 5.1 soft link pointing to the latest 5.1.y release and so on. The only problem that I can see is the storage of the ISO images; there's very probably going to be a need for storage of the latest 5.0 image, latest 5.1 image, etc. just like now the latest 3 (3.9) and 4 (4.5) images are stored. And, well, those images need to first be created, so there's going to be a need to create n+1 images at update step n. More work for the CentOS devs :-) Note: The thoughts expressed above come only from interpreting public information; I have no connection to Red Hat. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu at IWR.Uni-Heidelberg.De