[
https://issues.apache.org/jira/browse/DERBY-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490990
]
Andrew McIntyre commented on DERBY-2570:
----------------------------------------
The release notes that are included in the release are neither what we
currently have checked into the trunk as the current RELEASE_NOTES.html, nor
are they in JIRA in an easily manipulable format. The release notes that are
included in the release are going to be (in most cases) the work of the release
manager, including a summary, the list of application impacts and long form
release notes, and a list of bug fixes and new features and such. The goal of
this JIRA is to eliminate the mechanical steps to compiling the actual release
notes that will become part of the release. It should be, once completed,
checked into svn. Just as with the last several releases, long form release
notes should be put into JIRA, although we would now ask that contributors
attach them to JIRA as attachments using a template, instead of free form in
the comments.
So:
- the current RELEASE_NOTES.html in the trunk should be moved elsewhere, as it
is a template for the final product and not an actual set of release notes.
- a new template providing an outline of HTML markup for the long form release
notes should be added in the same place (tools/release/templates?
tools/templates?) along with instructions for filling it out and attaching it
to JIRA.
- create a tool which compiles the long and short form release notes from JIRA,
and incorporates a hand-written (or partially generated) summary provided by
the release manager who will be running the tool. Previously this had been done
by hand and the work described in this JIRA aims to alleviate this manual step
for the release manager.
- the compiled release notes would be put up for review and checked into svn
before release artifacts are generated.
The only difference from previous releases is that we would ask contributors to
provide long form release notes using the template described above and attach
it to JIRA, so that the automated tool could scrape it out of JIRA and compile
the release notes which much less manual effort. The tool could check that each
JIRA with 'release note needed' checked contained a long form release note, and
if the contributor does not provide one, or is no longer interested in
providing one, then it will still be up to the release manager to get the
release note into the necessary format so that it is included in the release
notes.
To address Bryan's concern, a long form release note attached to JIRA may be
part of one or several releases. A compiled set of release notes with
description (including specific version number), summary, and some set of long
form notes and short form bug fixes and features is meant to be distributed
with one and only one release. To address Dan's concern, I do believe that this
compiled set of release notes should be checked into svn before the release
artifacts are generated so that the final product becomes a part of the source
distribution and included in the subversion history.
> Create a utility which generates Release Notes
> ----------------------------------------------
>
> Key: DERBY-2570
> URL: https://issues.apache.org/jira/browse/DERBY-2570
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
> Affects Versions: 10.3.0.0
> Reporter: Rick Hillegas
>
> This proposal summarizes an off-list conversation among Myrna van Lunteren,
> Bernt Johnsen, Andrew McIntyre, and myself.
> Currently, there is a template for release notes in the top level directory
> of the code tree. Actually filling in this template is a time-consuming,
> error-prone process. We would like to automate this process as much as
> possible. We believe it ought to be possible to generate the Release Notes
> given the following inputs:
> 1) A high-level description of the release. The Release Manager would write
> this description, based on a template.
> 2) An xml report produced by a JIRA filter. The filter would list all of the
> JIRAs addressed by the release.
> In order for this to work, we would need for the community to agree on
> conventions for the release notes which are attached to JIRAs, viz., the
> JIRAs whose "Release Note Needed" toggles are turned on. These JIRA-specific
> notes become items in the Issues section of the final Release Notes. Each of
> these items calls the reader's attention to a significant topic involving
> Derby's behavior, that behavior's compatibility with previous releases, and
> adjustments which the user may need to make to her applications.
> The following approach makes sense to us:
> A) The community will agree on an html template for these notes.
> B) The note-writer will fill in this template and attach it to the JIRA using
> a canonical file name, say "releaseNote.html".
> C) Various iterations of the note may be needed.
> D) The utility for generating Release Notes will grab the latest rev of
> "releaseNote.html" attached to the JIRA.
> This effort involves at least two major steps:
> I) Getting the community to agree to these note-writing conventions.
> II) Writing the Release Note generator.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
