Andrew McIntyre wrote:
On 9/13/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:
Thanks, Andrew. Can you explain some more about what the above url
represents?
It's all issues marked Resolved and/or Closed with a Fix In of
10.2.1.0. You can navigate to that page by clicking the 'Release
Notes' button on the front page and then choosing the appropriate
options on the next page.
Since the release page is HTML, it's convenient to use the HTML
JIRA-generated release notes to make the section on the Derby release
page with the list of JIRA issues fixed, as the resulting HTML needs
minimal rework to insert into the release notes page.
I need to prune out a lot of these issues:
o Some of them are internal issues which end-users don't need to see.
E.g., code cleanup.
Just remove the corresponding lines from the JIRA generated release
notes. If you're searching for brevity, looking at the JIRA generated
page, all of the miscellaneous JDBC4 'new features', of which there
look to be about 16, could be removed and only "[DERBY-587] -
Providing JDBC 4.0 support for derby" left in the release notes.
I don't include the Task or Test sections.
This approach would work fine if I were generating Release Notes the old
way: as a follow-on job after actually vetting the release. However, we
have decided that we want to bundle Release Notes with the release
candidates themselves. That means I have to amend this list each time I
build a release candidate. I was looking for a solution which would make
it easy to sweep up the incremental slug of bug fixes which go into
successive candidates.
o Some of them were also fixed in 10.1.3.1 so we don't want to see them
If they really shouldn't be marked Fix In 10.2.1.0, it is better to
update the Fix In for the issue to not have 10.2.1.0 as one of the Fix
In versions so the data in JIRA is correct. Then just regenerate the
JIRA release notes.
Ah dear. There seems to be some controversy about the contents of that
field. I'm reluctant to touch it until we reach consensus about its meaning.
andrew
