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:


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:


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.


Reply via email to