[
https://issues.apache.org/jira/browse/DERBY-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923500#action_12923500
]
Rick Hillegas commented on DERBY-4857:
--------------------------------------
Thanks for the additional instructions, Kristian. I will take a closer look
later today.
Concerning the semantics of getAncestors(): I don't think we have an example of
the problem in our existing set of releases. We almost had an example involving
the following releases:
o 10.4.1.3 (released 2008-04-24), whose preceding release was 10.3.2.1
o 10.3.3.0 (released 2008-05-12)
The problem would have occurred if the release dates for 10.4.1.3 and 10.3.3.0
were reversed.
Let me try to restate the problem.
1) Suppose we have two active branches A and B where A < B. We have already cut
official releases off both branches: A.x and B.y.
2) We discover that we have a serious security or data corruption bug: NNNN.
3) We fix NNNN in both the A and B branches.
4) Then the community cuts a new emergency release A.x+ off the A branch.
5) Afterward, the community cuts an emergency release B.y+ off the B branch.
Note that precedingRelease( B.y+ ) = B.y NOT A.x.
Under definition (a), A.x+ is an ancestor of B.y+. That means that NNNN will
not appear in the release notes for B.y+. That's a shame because the reason
we're issuing B.y+ is to fix NNNN.
However, under definition (b), A.x+ wouldn't be an ancestor of B.y+ so NNNN
would appear in the release notes. Everything would be fine.
Note that the problem would not occur if we reversed the order of steps (3) and
(4). That is, we won't see the problem if the emergency release on the later
branch is produced BEFORE the emergency release on the earlier branch.
Hope this makes more sense now.
> 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.0.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.
