On 9/8/07, Karanbir Singh mail-lists@karan.org wrote:
Roger Peña wrote:
Well, I definitly can't see how the "3 sub-release deep" (4.5.x and 5.0.x, and so on) can work in the actual tree and procedure
the sub-releases will be like :
5.0.1 + 5.1.0 being released at the same time, and being the 2 release trees for CentOS-5 till such time as :
5.0.2 + 5.1.1 + 5.2.0 are released at the same time, which are then the 3 sub-releases for CentOS-5 till such time as :
5.0.3 + 5.1.2 + 5.3.0 are released at the same time.
I hope this clears things up. There is no such sub-release plan for CentOS-4 ( that I am aware of )
Actually.. that was in the air when we talked with sales.. the reasoning for calling it 4.6 versus 4U6 was to look at allowing that to happen... however it might be too much work and not enough customers.
break the now procedure to "hardlink" directory 4 --> 4.<lastversion>
that raises 2 angles to the same problem.
- should people be moved along normally, as we do now, by /5/ always pointing
at the latest version / newest set of packages - and let users opt-in to staying within a sub-tree, so they would need to manually choose to stay on 5.0.x when 5.1.x is released.
- We change the behavior completely and have /5/ only stay within the same
sub-release, so when 5.1.0 is released, /5/ only points at /5.0.x tree. users would then need to make the manual choice of moving their machines to 5.1.x tree.
Personally, I would like to go with what we have in place, and have /5/ always reflect the latest ( highest number ) release within 5.x.x . This is also less likely to cause orphaned machines when sysadmins dont make a choice at the end of life for a sub-release ( eg. 5.0.3 comes to an end, where do they go then ? since 5.3.0 would have now been released, and the changeset from 5.0.3 to 5.3.0 might be fairly large ). So I am going to vote for (1) above.
I agree and would like to vote for 1