[
https://issues.apache.org/jira/browse/HBASE-14025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628399#comment-14628399
]
Sean Busbey commented on HBASE-14025:
-------------------------------------
We're saying that the committer does still set the Fix Version/s to all
affected branches. It's the RM who laters things.
{quote}
if (say) 1.2.0 was not released, yet, but 1.2 was already branched the
committer has to remember that when committing to branch-1 which will be (say)
1.3.0
{quote}
Yes. And they can then set 1.2.0 and 1.3.0 as fix versions.
{quote}
* one cannot just copy the (again, say) CHANGES.txt from 1.2.0 (once it's
released) into 1.3.0 and fill in the 1.3.0 changes from jira. If jira is the
source of truth that should be possible
* I'd still want to see 1.2.0 changes, followed by the new 1.3.x changes, no?
* since we branch 1.2 before 1.2.0 is released (and hence branch-1 becomes
1.3.0) we can simply copy the CHANGES.txt from 1.2.0 and fill in the 1.3.x
changes, instead.
{quote}
This should be possible starting with 1.3.0. For 1.2.0 I had to go copy the
notes from 1.1.0 and 1.0.0 to build the CHANGES.txt file with all minor version
information.
If we left 1.3.0 as a fix version rather than have the RM clean it up as a part
of releasing 1.2.0, then we wouldn't be able to do this iterative building
because some of the jiras would be repeated in both the 1.2.0 section and the
1.3.0 section.
> Update CHANGES.txt for 1.2
> --------------------------
>
> Key: HBASE-14025
> URL: https://issues.apache.org/jira/browse/HBASE-14025
> Project: HBase
> Issue Type: Sub-task
> Components: documentation
> Affects Versions: 1.2.0
> Reporter: Sean Busbey
> Assignee: Sean Busbey
> Fix For: 1.2.0
>
>
> Since it's more effort than I expected, making a ticket to track actually
> updating CHANGES.txt so that new RMs have an idea what to expect.
> Maybe will make doc changes if there's enough here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
