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 )
break the now procedure to "hardlink" directory 4 --> 4.<lastversion>
that raises 2 angles to the same problem.
1) 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.
2) 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.