"Robert Ramey" <ramey@rrsd.com> writes:
As an observer, I'm fairly impressed with GCC's release methodology. http://gcc.gnu.org/develop.html
A critical component is a schedule that includes several stages during which certain sorts of changes are unacceptable.
There's still rush, but most of the rush for major features or other destabilizing elements happens long before the release comes around.
I found this to be very interesting. I had never seen this before. It basically implements my view that the "Main Line" should be code that is always works and is ready to be used, tested and potentially released.
Did you miss this part? Schedule Development on our main branch will proceed in three stages. Each stage will be two months in length. Stage 1 During this period, changes of any nature may be made to the compiler. I think they are willing to destabilize the main trunk at least during stage 1.
As far as I'm concerned it's totally consistent with my proposal which I thought was un-orthodox but now see that is used at least by GCC.
So, my view would be - stick to the original 28 June date, require that new libraries be added to branches and merge to main as appropriate.
I don't think there's any way we can do a release _today_, even with no new libraries ;-)
I realize its not THAT easy - but it would address the concerns that I have about the whole process and allow all libraries to proceed on independent schedules. New libraries would be tested against the "known good tree" independently of one another.
Take as a small example changes in MPL. The current method is to check in a new version of MPL and see what happens. Presumable some issues will arise and now we have a broken system which inhibits development of other libraries until the issues are resolved.
Under the proposed method, the new MPL would be check in under its own branch and issues would be detected on all libraries before they affect other developers.
First of all, a new version of MPL is the main motivation for this particular release, so we _are_ going to merge it in from its development branch (mplbook) before the trunk branches for release. Secondly, a core library like MPL may occasionally change its interface in ways that are not strictly backwards-compatible. If development of other libraries continues while MPL is on its branch, it may be unreasonable to expect MPL's branch to ever work with all those libraries' trunk state. At some point, you have to check it in and let the other libraries adjust. I like the idea of keeping the trunk healthy -- that's the way I always try to operate -- but I don't think that branching for release without warning or communication is reasonable, and I think you have to occasionally be willing to have major changes to core libraries moved to the trunk before you can guarantee that it will cause no trunk breakage. Boost is a collaborative effort, and we rely on communication and cooperation. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com