Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Date: Mon, 03 Aug 2009 16:24:35 +0200
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: DERBY-4331 and the 10.5.2.0 release
In-reply-to: <4A76E79C.5060307@sun.com>
Sender: Knut.Hatlen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <x6tz0pdlgc.fsf@Sun.COM>
References: <4A75C5FD.6060902@sbcglobal.net> <4A76E79C.5060307@sun.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (usg-unix-v)

Rick Hillegas <Richard.Hillegas@Sun.COM> writes:

> As I see it, data corruptions are the worst kind of database bug,
> followed closely by wrong results. We have a precedent for pulling
> releases from our download site and I recommend that we pull the
> 10.5.2.0 release because of this regression.

Although we have pulled releases with serious problems from our download
site once, I think we shouldn't make that the rule. The pulling did
cause some problems for us, like holes in the release notes when
upgrading over multiple releases in one go. And most of the releases
from the 10.3 and 10.4 branches did have wrong results regressions, but
they're still available for download.

However, since we haven't yet announced 10.5.2.0, holding the
announcment (possibly pulling the release from the download page) and
quickly re-spinning a release with DERBY-4331 fixed sounds like a good
option. Also, I'd prefer a quick re-spin as soon as the known
regressions are fixed, rather than having a new maintenance release in
the autumn, since right now all our 10.5 releases have known regressions
from 10.4.

That said, I won't be able to help with a release the next two weeks, so
I'm just expressing a wish for a quick fix, not actually offering to do
the work. :(

-- 
Knut Anders