On 02/10/2012 04:31 PM, Daniel James wrote:
On 10 February 2012 15:01, Julian Gonggrijp<j.gonggrijp@gmail.com> wrote:
Note (1): my depiction of the current Boost workflow might be inaccurate. If you see a way to improve the image, please go ahead or let me know what needs to be changed.
You've actually over-estimated our process. We never do a complete merge from trunk to release, just either cherry-pick changes, or do a sub-tree merge. There are often long neglected changes in trunk - which is a major problem with the current system.
Note (3): while this image helps to explain my point in [1], it turns out from [2] that I didn't actually address Daniel James' point. I'll return to the testing issue in a new reply to [2].
Having thought about it a bit, it might be the case that I exaggerated the issue. It certainly matters to me, but I'm not sure about other developers. A lot of the newer libraries don't put much effort into supporting the more obscure compilers.
Well, i still like to believe that one of boost's strengths is the large platform support. This is also the reason why I believe that a branching model is not a good solution for boost. Here is why: When i develop a new feature i do that on trunk, whenever i feel confident that the feature works as i expected it, i commit it. After a couple of days the test cycled, and i see on which platforms these tests fail and i try to fix it. This is where I have problems with this whole branching model, when will my features i pushed to a branch be tested? I actually believe that despite the possible ease of development and contribution such a model actually leads to a unstable main branch or trunk. I think testing should be a concern, and i would rather like to see a discussion about test improvements than VCS. However, if a different VCS means easier testing (for the test runners), I am all for it. I am curios to hear more about that! Regards, Thomas