joaquin@tid.es wrote:
Do you think it will work? You basically want users to grab new Boost, build it, update their source code, and do automatic and manual QA. And all this during 2-weeks window. And further, if user runs into a bug he has to fix it, or discuss with Boost developers, and this means maintaining two branches of the code, which the associated overhead.
What's the purpose of having a beta then if not to let users test the code before the final release? If two weeks is too little time maybe we should consider extending it, but undergoing a beta period without actually expecting to receive users' feedback makes no sense to me.
I guess that the only feedback we can practically expect is that the next release is not a brick. Maybe also some feedback about cool new features that users are dying for -- if such features are advertised properly. Interface-breaking changes in a specific library are likely to be missed, so *if* we want interface compatibility in some form, we need some other mechanism in place, for example: * A policy that interface breakage need to be discussed * Running old release tests against new Boost version * Dot releases - Volodya