Any reply on below? - Volodya
[I though I've replied to this, but I don't see the reply -- which I definitely wrote -- neither in sent nor drafts folder. Apologies if somebody gets reply twice]
Rene Rivera wrote:
Vladimir Prus wrote:
Rene Rivera wrote:
Since I don't enjoy reverting changes when I don't have the time (I'm in the middle of my own product release). And since Boost is nearing the end of a release cycle. *ALL* tool changes are hereby *FROZEN* except for emergency fixes. Any changes must be approved by Beman or myself. And such changes must include making sure Boost testing runs adequately in *both* a Windows platform and a Unix platform. This means going to the boost-root/status directory and running the tests for *at least one* library, but preferably all of them.
Thank you for paying attention.
Pardon me, but what the hell? Do I really need to explain that branches in version control systems are intended specifically so that you don't have to *SHOUT IN EMPHASIZED UPPERCASE* whenever development branch, also known as trunk, gets broke? Or do we to understand that 1.36.0 beta 1, which is due due days ago, is going to be rolled from trunk? Or for some unknown reason, the testing process for release branch uses tools from random other branch?
1. Trunk is not the "development" branch.
Well, the wiki is very clear on that:
Trunk The main development and test location.
So, as documented, it *is* development branch.
We've said in the past, as part of the new release procedures, that it should be maintained in a stable form. And that "development" should be done in branches as needed by individuals. This hold for tools just as much as it holds for libraries.
I don't think I know of any project that believes that it's OK for trunk to be broken (as in, regression tests failing) for a significant periods of time. But on the other hand, I don't think I know any project where issues appearing in trunk result in immediate revert of the commit. I don't think the Boost wiki documents such drastic approach either, and I don't think it should.
The commit in question is an isolated commit, which is not part of any major rework supposed to caused any instability. "Developing" it on branch would be fairly weird, and given that we don't have any way to run tests on random branch, it might not prevent any mistakes.
2. Testing uses the BBv2 tools from trunk because it's been pointed out before, not sure if it was you, that the trunk BBv2 tools should be the ones released with the Boost releases. Hence we need to test with those tools. I'm more than happy to have a BBv2 release that we could use for testing that is sufficiently stable and has all the needed fixes for a Boost release.
I don't think I said exactly that. I do think that on the average, any random snapshot of Boost.Build is strictly better than either the previous release, or the state included in previous C++ Boost release, and so trunk state at some point should be automatically included in next C++ Boost release. But I never said you should use "live" trunk version for C++ Boost releases, precisely for the same reason you don't use "live" trunk version of any individual library.
As soon as merge from trunk to release branch is made, the release branch version of Boost.Build should be used for testing the release, and only fixes for issues found during such testing should be further merged. There's no need to make formal release of Boost.Build, just as you don't require separate formal release of each Boost library to be included in upcoming C++ Boost release.
So, what prevents using release version of Boost.Build, and other tools, for testing the release? Can you adjust the testing infrastructure to do so?
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost