[
https://issues.apache.org/jira/browse/HBASE-14025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14616018#comment-14616018
]
Enis Soztutar commented on HBASE-14025:
---------------------------------------
bq. Correct, it removes 1.3.0 because a previous minor release (1.2.0) included
it. It doesn't remove 2.0.0 because the fix was not in the prior major release
(1.0.0), so there will likely be future minor releases on the previous major
release that are not in the initial 2.0.0 release.
I think I get your point, but not sure how easily we can follow this practice.
It gets complicated for committers to think about what fixVersions to set at
the time of the commit. The thing we have where we just mark the next scheduled
version from that branch is simple and worked so far.
bq. As for differentiating between things committed after branch-1.2 is forked,
why would we need to know something went into both branch-1 and branch-1.2?
It's the norm.
bq. Put another way, what's the value to me as a consumer of the 1.2
CHANGES.txt for including just those fixes that are in 1.1.0 from after the
branch point?
Agreed that the CHANGES.txt can be filtered out for easy consumption. As a
consumer of CHANGES.txt, you may not care about whether the change went in
before the fork or after the fork. As a developer / committer though, I prefer
to have the fixVersion there just to make sure that all branches are covered at
the time of the commit. It is preferable to err on the cautious side.
Can we do a middle ground where we keep the fixVersions in jira, and filter
them out in CHANGES.txt for convenience if not needed?
> 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)
