On 9/12/11 9:25 AM, Myrna van Lunteren wrote:
On Mon, Sep 12, 2011 at 6:00 AM, Rick Hillegas<[email protected]> wrote:
On Fri, Sep 9, 2011 at 8:53 AM, Dag H. Wanvik<[email protected]> 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
