[
https://issues.apache.org/jira/browse/HBASE-14025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14615908#comment-14615908
]
Enis Soztutar commented on HBASE-14025:
---------------------------------------
i think the discrepancy is due to the fact that we mark all active branches
that the fix went in, for example, today we are marking an issue with 1.2.0,
1.3.0 and 2.0.0 if it was committed to branches branch-1.2, branch-1 and
master. By the time, 1.3.0 release comes up, the jiras with fixVersion = 1.3.0
will include 1.3 exclusive patches + patches in 1.2.0 and earlier.
[~busbey] I have noticed that you have been unmarking some of the fixVersions
in jira (for example HBASE-13895). Is this for clean up for CHANGES.txt for
1.3.0 or some general cleanup? I am asking to understand whether we need to
refine the process.
At the time of the HBASE-13895 commit, there was already branch-1, branch-1.1,
branch-1.2 and master branches. Thus, the jira used to bear {{2.0.0, 1.2.0,
1.1.2, 1.3.0}}. Your process above (correct me if I am wrong) removes 1.3.0
from fixVersions since 1.2.0 is the first release that will have that patch?
How do we differentiate the fact that the issue has actually been committed
after the branch-1.2 is forked, and committed to both branch-1.2 and branch-1?
> 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)
