db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: First Draft 10.8.2 release notes
Date Mon, 12 Sep 2011 17:53:32 GMT
On 9/12/11 9:25 AM, Myrna van Lunteren wrote:
> On Mon, Sep 12, 2011 at 6:00 AM, Rick Hillegas<rick.hillegas@oracle.com>  wrote:
>>>> On Fri, Sep 9, 2011 at 8:53 AM, Dag H. Wanvik<dag.wanvik@oracle.com>
 wrote:
>>>> [...There] are not user visible changes and could be left out, I think.
>>>>
>>> On 9/9/11 2:40 PM, Myrna van Lunteren wrote:
>>> [...]I didn't think I should manually adjust the release notes.
>>>
> [...]
>> If people feel strongly that the release notes are too verbose, then we
>> should discuss how to flag noise issues in JIRA. That way we can
>> programmatically exclude them from the filters. It's late in the day to do
>> this for 10.8.2 but we could consider this change for 10.9.
>>
>> Thanks,
>> -Rick
>>
> I don't want to do this for 10.8.2.
>
> I think perhaps a 'development only' or 'internal' flag could be used
> to mark issues that would not be useful to end-users.
>
> I was wondering whether we want to go back to having 2 files or have 1
> Release Notes file with 2 sections.
Kristian has made the tools smarter so that now they create their own 
filters on the fly. It should be possible for the tools to create a 
number of filters on the fly and to divide the issues into groups like 
the following:

1) Externally visible behavior changes which should be interesting to a 
large audience.

2) Documentation changes.

3) Testing and internal changes (like refactorings and other cleanup) 
which are interesting to Derby developers and maybe to people who build 
their own, custom distributions.

> (We had at one point the "changes" file in addition to the release
> notes, but if I remember correctly, the difference between the two
> wasn't clear).
As I recall, the CHANGES file lived in the distributions, not on the 
download website.
> I lean slightly in favor of 2 different files - so that someone can
> pass on only the end-user relevant file. Perhaps the other file could
> be called e.g. Derby_Project_Notes...(I find it difficult to come up
> with a name that clearly separates developers using derby from
> developers of derby).
I'm a fan of putting all of the information in the release notes but 
using appendixes to hold the information which has a smaller readership. 
Having all of the information in one file that is on the download site 
makes it easier to reconstruct the composite list of changes along a 
multi-release upgrade trajectory.

Thanks,
-Rick
> But now first I need to make a release.
>
> Myrna
>


Mime
View raw message