Eric Niebler wrote:
Vladimir Prus wrote:
Folks, I would have like to merge Boost.Build state from trunk to release branch. This matter was discussed briefly in
http://thread.gmane.org/gmane.comp.lib.boost.devel/180814/
but it didi not lead anywhere, and further it seems to be some confusion between merging Boost.Jam (which Rene wants) and merging Boost.Build.
To reiterate, I think Boost.Build should be merged because:
- it now supports linux->windows cross compile - it allows to eliminate configuration warning messages from libraries that are not built (which requires corresponding merges for libraries Jamfiles, but it's trivial) - it fixes a bug where include=/foo/bar could not be specified on the command line - it has some other smaller fixes - I don't see any breakage on trunk tests
Comments?
The development process should work like this: you make a change to trunk, wait for tests to cycle, and if they look good, you merge the change to release. The process should *not* work like this: you make change after change to trunk, and wait until the very last minute to drop them all into the release branch at once.
I disagree. By requiring a test run after each change you impose very high additional overhead and slow down development considerably. No other project has such requirements. If trunk has 30 changes, and the end result has good test results, it is a waste of time to run tests on 29 intermediate states that are not meant to be used.
Some of these improvements are desirable, though. Can you send links to the changesets you'll be merging? And describe potential impacts?
I'll be merging everything, as discussed later in the thread. - Volodya