At 12:59 AM +0400 9/2/07, Vladimir Prus wrote:
2. Say Boost 1.35 is released. Week later, a big source-incompatible change to some library is merged to release-ready tree. Week later, a serious bug is found in another library. Is there a place where that bug can be fixed? Release-ready tree already has source-incompatible change to other library? In other words -- from which tree is 1.35.1 going to be released?
Being a user of boost, I would suggest the answers be a. The bug fix should be made to the release-ready branch, assuming it satisfies the processes for doing so. Since the bug is described as serious, the relevant library author has a pretty strong incentive for getting the bug fix through the release submission process. b. By default, there is no 1.35.1. This might be considered contentious by some, so I will give some arguments in support of that position. Boost is an open source project. If a user needs a bug fix back ported to an earlier version (even the latest release), that user is free to do it themselves, or convince someone else to do it for them, possibly by hire. If there are enough users for a particular release wanting bug fixes back ported, they could even band together and amortize the cost of "professional" support. The author of the library containing the bug might choose to do that backport and make it available as a branch that users can merge from, but I don't think that should be a requirement. Who would decide what bug fixes go into a 1.35.1,2,3,... release? Different users may have different needs there. One user's show stopper bug might be in another user's "too risky" category. Boost is an all volunteer effort. It is producing stuff that is clearly useful to a lot of folks, and of very high quality. I think this volunteer effort should remain focused on that library development, and not get bogged down in dealing with more configuration management issues. Keep moving toward future improvements, and don't worry to much about past releases.