[
https://issues.apache.org/jira/browse/DERBY-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491345
]
Daniel John Debrunner commented on DERBY-2570:
----------------------------------------------
> 1) By editting a JIRA's one line summary, you affect the JIRA's summary as it
> appears in the pamphlet.
I think this is the wrong approach. For something that can affect existing
applications it is the behaviour change resulting from the Jira entry not the
entry itself.
For example, DERBY-1384 in 10.2
The summary in Jira is:
Increase default BLOB/CLOB length to maximum supported (2G?)
which was cleaned up (incorrectly) in the release notes as
Maximum BLOB/CLOB length has increased to 2G-1.
But that's not what existing applications need to be aware of. They need to
understand that due to this change columns that are declared as BLOB/CLOB now
will not reject values larger than 1M and if their application depended on
that, they need to make changes.
Changing the summary for DERBY-1384 would be wrong, it's correct.
The summary for such a change in behaviour needs to highlight how it might
affect/break applications so that an application developer is more likely to
read it.
Maybe separating the release notes from Jira and just have a single file
release_notes.html file with the actual contents would work.
> 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
> Attachments: releaseNote.html, releaseNote.html
>
>
> 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.
