[
https://issues.apache.org/jira/browse/HBASE-14025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621132#comment-14621132
]
Andrew Purtell edited comment on HBASE-14025 at 7/9/15 7:42 PM:
----------------------------------------------------------------
{quote}
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.
{quote}
I think it's fine for the RM to do this cleanup on the eve of the first release
of a new minor version. At such time we start having fixVersions = { 1.3, 1.4,
... } and it's time for the first 1.3.0 release, the 1.3 RM can drop all of the
1.4 fix versions where the changes are going out in 1.3. And so on.
Edit: Likewise, if there's something going out in 1.3 that doesn't have that
fix version, the RM will need to set it. There's some homework and burden
placed on the RM to be sure. However other alternatives seem less optimal to me.
was (Author: apurtell):
{quote}
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.
{quote}
I think it's fine for the RM to do this cleanup on the eve of the first release
of a new minor version. At such time we start having fixVersions = { 1.3, 1.4,
... } and it's time for the first 1.3.0 release, the 1.3 RM can drop all of the
1.4 fix versions where the changes are going out in 1.3. And so on.
> 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)
