Douglas Gregor wrote:
On Aug 1, 2007, at 12:02 AM, Stefan Seefeld wrote:
What are the next steps ? If I understand correctly, the 1_34_0 branch should now be copied to, say, 'stable', such that in regular intervals things can be merged in from the trunk. Am I reading the suggested procedure correctly ? (And then, at some point, 'stable' can be branched to '1_35', etc....)
That is my understanding, although IIRC, the last discussion ended up with, "We can finalize the new procedure later, once we have moved to Subversion." Personally, I'd like to see us find a good way to turn "stable" into an actual release branch of "trunk", with the appropriate svmerge.py tags to make it easy to keep it up-to-date. The trunk/stable divergence is really bad for future development.
Yes. I think it would be good to a) identify a 'stable' branch (from which the next release branch will fork) and b) establish a policy concerning checkins (for example, merges of stable change sets from trunk). Right after 1.34 came out, people suggested that 1.35 should follow shortly, with the most important changes being new library additions that were accepted before 1.34 but didn't make it into the 1.34 release branch. Thus, now would be a good time to allow project owners of such libraries to work on that.
Also, what branches are the tests being run on, and triggered by what event ? I'd expect some testing on trunk, and some on stable (though at least the latter not nightly, since check-ins should occur less frequently. Correct ?
Until someone gets regression.py updated to work with Subversion, no tests are run. My understanding of the new testing scheme is that most of the testing will go on the trunk, but that we'll also periodically test the stable branch (less frequently). No triggers; I expect perhaps 2 days of the week will test stable, the rest testing trunk. Or, for those with the resources, test both nightly.
I'm looking forward to a buildbot setup that makes such things easier. (Rene, if you need help, I'd like to contribute...) In particular, writing schedulers that trigger builds / test runs either by time or by checkins ("triggered by a checkin but no earlier than x minutes after a checkin", "no more than twice a week", etc.) Having regular test runs on 'stable' should be a requirement for allowing merges from trunk, to avoid the branch becoming unstable. On a related note: the boost tracker has milestones for the 1.34.1 release (still not closed) and 1.35.0. It would be good in addition to the existing issues assigned to 1.35 to define goals, such as what new libraries are expected to be merged / integrated. This has the advantage that users know what to expect from the next release, and developers what work remains to be done. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...