[
https://issues.apache.org/jira/browse/DERBY-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923971#action_12923971
]
Rick Hillegas commented on DERBY-4857:
--------------------------------------
Thanks again for the patch, Kristian. I updated my client, which got me past
the build issues. After that, I was able to test-drive the patch and
successfully build the release notes. Love it. A couple comments:
o It would be nice if the tool had a quiet mode. Maven is pretty chatty and
yours truly doesn't need to see the list of excluded bugs.
o Maven coughs up the following warning. It didn't seem to hurt anything but
I'm probably not the only person who will be puzzled by it:
WARNING: Unable to find required classes (javax.activation.DataHandler and
javax.mail.internet.MimeMultipart). Attachment support is disabled.
o I had to remove the following sanity-check from ReleaseNotesGenerator (line
282). It will kill release notes generation for feature releases. That is
because the release manager wants to publish the release notes a good week
before creating the branch and building the first release candidate. At that
time, the version number in release.properties is still an alpha version
number. I tripped across the fact that the version number in release.properties
on the trunk was 10.7.0.0 but I was trying to generate release notes for
10.7.1.0:
else if (!relVer.equals(releaseID)) {
throw new IllegalStateException("target release version mismatch " +
"between release.properties and bug list: " + releaseID +
" != " + relVer);
}
I think that the release number which appears in RELEASE-NOTES.html should
originate with the release number which you specify when you run "java -jar
target/JiraSOAP-LATEST-jar-with-dependencies.jar".
At this point, you have removed one of the redundant places where we specify
the release number (namely, in releaseSummary.xml). That's progress. I don't
think we need to sand this down further, although it's worth thinking about
streamlining how many times we still specify a release id:
o We specify a release id when we define the jira filter which defines the raw
stream of bug ids.
o We specify a release id when we run "java -jar
target/JiraSOAP-LATEST-jar-with-dependencies.jar".
o We specify a release id when we run the master target which builds the
release candidate.
Here is the script which I used to tie together all of the pieces of
release-notes generation. This may be useful to other release managers who want
to test-drive this patch:
Thanks,
-Rick
----------------
#! /bin/bash
#
# Run the machinery which creates the release notes. Make sure
# that you are not on a corporate VPN--otherwise maven may hang
# while trying to access the network.
#
# Arguments:
#
# $1 jira user name
# $2 jira password
# $3 release version (e.g. 10.7.1.0)
# $4 numeric id of filter used to create jira report of fixed bugs (e.g.
12314683)
#
# E.g.:
#
# createReleaseNotes rhillegas mypassword 10.7.1.0 12314683
export jiraname=$1
export jirapassword=$2
export derbyversion=$3
export relnotesdir=$HOME/junk/$derbyversion-relnotes
export filterid=$4
export destinationfile=$relnotesdir/fixedBugsList.txt
export remove=true
mkdir $relnotesdir
cd $BRANCH/tools/release/jirasoap
# build the application which uses SOAP to tease information out of JIRA
mvn -Pbuildclient
# now produce the filtered list of issues
java -jar target/JiraSOAP-LATEST-jar-with-dependencies.jar $jiraname
$jirapassword $derbyversion $filterid $destinationfile $remove
# now generate RELEASE-NOTES.html from the filtered list
cd ..
ant -Drelnotes.src.reports=$relnotesdir genrelnotes
> Utilize the SOAP API to fetch JIRA issue list for release notes generation
> --------------------------------------------------------------------------
>
> Key: DERBY-4857
> URL: https://issues.apache.org/jira/browse/DERBY-4857
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
> Affects Versions: 10.7.1.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Attachments: derby-4857-1a-jirasoap_relnotes.diff,
> derby-4857-1a-jirasoap_relnotes.stat
>
>
> Somewhat simplified, the release manager (RM) must currently perform the
> following manual steps to feed the release note generate the data it needs:
> a) Create manual JIRA filter to select issues addressed by the release.
> b) Save the filter result to disk as XML.
> c) Write/modify the XML parser to be able to parse the report.
> d) Determine and record all JIRA release note attachment ids for the issues
> requiring a release note.
> By using the current version of the SOAP API (3.13.5), steps (b) to (d) can
> be removed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
