Hello all, Time marches on, and preparations for the 3.1 release candidate are already underway. Please note, due to a personal scheduling conflict, I am delaying the official cutoff for the RC by one day. You now have until 2:00pm (EDT) on Thursday, March 22, to push reviewed bugfixes freely to master. After that point, there should be time for a few more fixes to trickle in, but please make sure I am aware of them. The intended goal is still to have the release candidate built and posted by end-of-day on Friday, 3/23.
When the RC is cut, I will also create a *working* branch for rel_3_1_0. My intention is to make sure 3.1.0 final is as close to the RC as possible without officially closing down master (or branching off rel_3_1 quite yet). What this means, functionally, is that you can continue to work normally, but do not assume that fixes pushed into master next week will be part of 3.1.0. I will try to watch and pull in anything which seems critical, but do not hesitate to contact me if something you review and push looks like a potential release blocker, and I will review it also for possible inclusion in 3.1.0. This is a bit different from past releases, so if any of this workflow is unclear, please ask and I will try to clarify. Here, again, is our standing list of bugs targeted at the RC: https://launchpad.net/evergreen/+milestone/3.1-rc I consider anything "High" or "Critical" to be a release blocker, and as I write this, four unfixed bugs meet that criterion. Of those four, three appear to be moving along, but one is relatively new and without a fix, so eyes there would be appreciated: https://bugs.launchpad.net/evergreen/+bug/1755502 I made a quick pass through all the "Undecided" RC bugs to look for other blockers, but didn't find any. If there are any bugs besides these four which you feel should be a blocker, please bump up their importance and/or target them at 3.1-rc. We don't want any surprises! Finally, I want to briefly address the recent thread concerning general discouragement due to the bugs in the web staff client. It feels a bit odd to be drumming up a new release while so much dissatisfaction exists with the general quality of our existing code. Evergreen releases have always focused on the timely review and release of new features, while fixes are meant to be a continuous process. Something I didn't realize until it was too late is that the prime time for fixes to stable code are the 2-3 months immediately *after* each x.y.0 release, not those leading up to it. With renewed conviction, I want to assure the community that my intention to make Evergreen 3.1 the best release possible will not end with the 3.1.0 release next week, but will continue in the weeks ahead in whatever ways I can find to realize that goal. Sincerely, Dan
