Peter Dimov wrote: [...]
Yep. This is how things were intended to work. The question is whether we need to reevaluate that. The single branches/release presupposes that only one release is active at a time. Given the proposed schedule, this can only be true if we drop the .1 releases. If we don't, it might be wise to revisit the old practice of using a separate branch for every release family - release_1_35, release_1_36, and so on. It might also be interesting to give the "starting point" question another look. I think that the trunk is quite competitive as a starting point for 1.36, because it is currently being integration tested, whereas release+merges is not.
The discussion in this thread resembles the one about which branch 1.35 was to be based on. Although the much shorter delay makes it a smaller problem, a "runaway" trunk is still a problem. Given how cheap branches are in svn I don't think it makes much sense for trunk to be the sort of anarchic playground it appeared to be at times in the past. In my opinion all releases should be based on trunk and branched immediately before the first release candidate is issued. Most development activity should take place in specific branches that are merged to trunk at appropriate times. For instance immediately after a release branch is created would be a perfect moment to merge new libraries in. Whether point releases take place would depend on the availability of fixes and of release management voluntaries, but making them should be as simple as possible. This is more or less how it is done for gcc, and it appears to work for them. Cheers, Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/