hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-14025) Update CHANGES.txt for 1.2
Date Thu, 09 Jul 2015 19:43:05 GMT

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

Mime
View raw message