Stabilizing the Tiger Release
In response to my recent blog on the Tiger Release Candidate, I've had
a few people follow-up on specific bugs they'd like fixed. Now, whenever
I see any specific bug description I always have a quick surge of
frustrated empathy and I want to rush out and make sure it gets fixed
asap. But then I take a deep breath and think of the larger picture...
Overall, we think Tiger is on track to be our highest quality release
ever. Happiness! But unfortunately that doesn't mean (and can't mean)
that it is bug free.
There is an agonizing tension in getting to high quality. To
achieve stability, you have to become really paranoid about change management,
especially late in a release. Since beta1 we have been increasingly
cautious in bug analysis. We've tried to make sure the key bugs get fixed, but
we've also deferred some bugs, in order to manage the rate of change
and to make sure we keep a high level of overall stability. Some of these
may get addressed in the Tiger update releases (5.0_01, 5.0_02, etc.).
In some of our early JDK releases we were aggressively fixing
lots of bugs even very late in the release. Well, unfortunately,
that didn't actually lead to high quality releases.
Every bug fix is also a bug risk, even
for those small fixes that "are clearly totally safe". Our history
is that even heavily reviewed "totally safe" fixes sometimes aren't.
I'm sorry that not every possible bug fix has gone into Tiger. But
we are doing a balancing act and the engineering teams have been
carefully assessing all the candidate bugs. I know
priorities can look different from different angles (especially if
a given bug is interfering with your app!) but we've been trying to
be thoughtful and to balance for the overall community good. Tiger
contains a lot of important new features and also a lot of significant
bug fixes and we want to deliver it to the community in a safe and
That requires a driving focus on stabilizing the release and thus on
progressively clamping down on change. I know this is an imperfect
process, but we try to make the best choices we can.
Our main concern at the Release Candidate stage is to Not Break Anything(tm).
The goal of RC is mostly to discover if we've had any significant "accidents"
due to the fixes introduced since Beta2.
Right now we are mostly seeing the RC status we expected.
Overall we have extremely high quality, but
with some previously diagnosed bugs.
RC is suposed to be essentially the final bits. The Sept 30th
target ship date leaves room for one last respin, in case we had
introduced some major late-breaking problem in RC.
But if there are no critical show stopppers we might
skip the respin and ship a little sooner.