Hello all,
Since the 1.5.x release process fiasco, I've been doing a lot of thinking about
how to avoid that situation in 1.6.x. These are some of my ideas, and
ultimately they form the basis of how I'm planning on proceeding with the 1.6.0
release.
Branching 1.6.x will happen sometime during the first couple weeks of November.
This is flexible, but we should try to be as close to that time frame as
possible. If features aren't quite ready for release by that time, we'll can
pull 'em and they can wait for 1.7. We already have enough new features to
justify a release by the end of the year.
As soon as the branch happens, I'll roll 1.6.0-pre1. I'll continue with weekly
-preX releases until there are no known issues, as which point I'll roll
1.6.0-rc1. If we don't have any known issues when we branch, I'll skip the
-preX series. The purpose of the -preX series is to get code from the branch
released soon and often, even if we are still working on stabilizing known
issues. Hopefully your testing environments are well scripted by now. :)
Once 1.6.0-rc1 is released, I'll follow the standard soak process, with a final
RC the week before release. Release Candidates should be just that: code which
is ready for release, and which we'd feel perfectly comfortable releasing as the
final release. Let's not have 11 "release candidates" before we find one we can
actually release.
I don't think these ideas are radically different than we've previously done,
just a little bit more formalized. Feedback is welcomed and encouraged.
-Hyrum
Received on 2008-09-17 03:46:51 CEST