
On Sat, Oct 26, 2013 at 9:39 AM, Daniel James
On 25 October 2013 13:22, Beman Dawes
wrote: That would mean an actual switchover starting about November 11.
It seems to me we need approximately a week after svn is made read-only and the final conversion run is done to verify the correctness of the conversion. During that time it seems to me that it would be unwise for developers to make git commits since if a serious problem was discovered we might decide to rerun the conversion process, wiping out the git repos.
At that point (roughly November 18, we would go totally live and developers could resume their work, now using git and modular boost.
I've added these dates to the calendar. Any thoughts on what I should put for the 1.56 schedule? Is there an equivalent of closing the release branch?
For the individual libraries, the rhythm will different. That should become clearer over then next couple of weeks as we generate more documentation. For the Boost super-project, the mechanics will be different but I think the big picture remains similar. Let's set the release date using the usual formula. Perhaps set the beta release date a week earlier than usual to allow plenty of testing. I'm wondering if a planned alpha release would also be a good thing? Its objective would be to work the kinks out of the release procedure, so it would just contain whatever updates happen to be ready. Cutoff dates would be unnecessary - given Git's easy branching and merging we could do an alpha without bothering developers with closing our main branches. Beta and final releases may end up being similar to the alpha. There would be cutoff dates that have to be met to get changes into the release, but maybe we can eliminate the need to actually close branches. I'd say go ahead and set some dates, with the caveat that they will change as our planning firms up. Thanks, --Beman