db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4857) Utilize the SOAP API to fetch JIRA issue list for release notes generation
Date Thu, 21 Oct 2010 16:24:15 GMT

    [ 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.


Mime
View raw message