hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Busbey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14025) Update CHANGES.txt for 1.2
Date Tue, 07 Jul 2015 00:54:04 GMT

    [ https://issues.apache.org/jira/browse/HBASE-14025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14616000#comment-14616000

Sean Busbey commented on HBASE-14025:

Sean 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.

Yeah, I was proactively trying to make the 1.3.0 RM's job easier.

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?

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.
For example, say we release 1.3.0 in August and 1.4.0 in November, then 2.0.0 in January.
When 1.5.0 comes out in February, it will contain fixes not present in the 2.0.0 release,
so we need a way to know that fixes are in 2.0.0 just as we needed a way to know when a fix
for e.g. 1.1.1 is also in 1.2.0.

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. It's only rare that
something goes into the minor release branch and not into the "future dev" branch (e.g. the
DLR-opt-in for 1.1 listed above). In the rare case we call out in the jira that it's only
for e.g. 1.1 and not future releases. If it was a mistake that missed the future dev branch,
then the process above will also catch it without needing additional markers in jira.

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? The vast majority of other
changes in 1.1.0 form before hte branch point are also in the code I'm getting. Given the
above process for making CHANGES.txt, those changes from post-branch will be included in the
section explaining what changed in the prior minor release.

> 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

View raw message