Robert Ramey wrote:
The development process for libraries, at least that on
http://svn.boost.org/trac/boost/wiki/ImprovingPractices
does not require that library changes be changed piecemeal, and as I say in other email, I think it would be a mistake to require piecemeal merge of changes. It only imposes additional overhead.
I would agree with Validir on this. I see the process where one makes (maybe alot) of changes in the trunk and once in a while gets to a point where he thinks - this is a real improvement over the current release ready branch and then does the merge.
Yes, agreed. The granularity at which things get merged to release should be at the feature level and bug-fix level, not the per-commit level. Thanks for correcting me. It seemed to me that Volodya was merging many complete and separate features at once. I'm saying a more piecemeal approach would prevent this sort of hand-wringing about destabilization. But since the release branch had been tested with BB from trunk, my hand-wringing was unnecessary.
Speaking of early freezing, I think we should be pragmatic. ....
I would like to see all tests run with the boost build and boost test in the release ready branch. This would permit developers of these tools to feel comfortable about commiting changes which might break something without creating a lot of problems for those using these tools. This would permit boost build to progress at its own schedule and pace while maintaining an ever improving product for use by boost and others.
Agree.
This would eliminate the requirement for any kind of "freeze"
Let me understand ... it would eliminate the need for a tool freeze *on trunk*, not on release. A freeze on the release branch is essential and standard practice. And IMO the freeze on tools should happen earlier ... by some weeks as Volodya suggested ... than the freeze on libraries.
The same goes for boost documentation which I would really like to use. But I don't feel confident that "it just works"
Heh, there's nobody here who would disagree with that. -- Eric Niebler BoostPro Computing http://www.boostpro.com