Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (athena.apache.org: 32.97.110.153 is neither permitted
 nor denied by domain of qozinx@gmail.com)
Message-ID: <47E134ED.8060203@gmail.com>
Date: Wed, 19 Mar 2008 08:44:45 -0700
From: Army <qozinx@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Release notes for Wrong Results bug...
References: <2107665427.1205878464438.JavaMail.jira@brutus>
In-Reply-To: <2107665427.1205878464438.JavaMail.jira@brutus>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit


Dyre Tjeldvoll (JIRA) wrote:
> 
> This issue has fix version 10.4 and is marked with either 'Release note
> needed' or  'Existing application impact', but does not have a
> releaseNote.html attached to it.  Should it?

I think Wrong Results bugs like DERBY-3023, DERBY-2351, and DERBY-3301 
have "Existing application impact" checked because the solutions to 
those bugs could change the query results seeen by existing apps--esp. 
we're now getting correct results where we were getting incorrect 
results before.

It seems like having a release note for such cases would be worthwhile 
so that users who see different results after upgrading to 10.4 can look 
at the release notes to get an idea of what may have caused the change.

Some example release notes for "wrong results" bugs can be found for 
DERBY-2256 and DERBY-1852; the latter is more detailed than the former. 
  Note, though, that someone on the list mentioned a long while ago that 
use of the term "may now return different results" in the "Summary of 
Change" section is not desirable since "different" does not imply 
"correct".  (I don't have the thread handy.)  Just changing "different" 
to "correct" doesn't help because then it would say we *may* now return 
correct results, which isn't good.  Removing "may" and just saying "now 
return correct results" is also a tad undesirable as it seems to suggest 
that the types of queries in question always returned incorrect results 
before, which isn't necessarily true (sometimes it depends on the data). 
  But maybe that's the best way to go...

Army