Beman Dawes schrieb:
Although it does look like we will be able to hold to a quarterly release schedule, it is really doubtful we have enough resources to issue point releases.
To get bug fixes into user's hands more quickly, should we provide hot fixes when appropriate?
As a user who has been hit by the filesystem problem: Actually, better no. Let me explain why: I've tried Boost 1.36 on a branch, to find exactly this kind of problem. Now I noticed that something has been broken, I have two (well, three) options: * I can back off updating to Boost 1.36, wait for 1.37 (at most 3 months), and then continue to use the deprecated functionality (no work on my side, just waiting) * Update my code now to the new API from Boost 1.36 (* Patch my copy of Boost. This is something I really want to avoid, and in a corporate environment, it's even more difficult to patch 3rd party libraries) If the release cycle is really predictable and every 3 months, I seriously doubt there will be any kind of bug that warrants a point release in between (with QA etc.). The only thing which would have helped me would be some documentation what has changed from 1.35->1.36 and how to update to 1.36 (i.e. changed APIs etc.). Known issues could be documented just like this, so if something got totally broken, users would have to wait at most 3 months to get it fixed. Cheers, Anteru