From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2007-08-01 09:46:02
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
>> 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.
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk