[
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:
-------------------------------------
{quote}
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.
{quote}
Yeah, I was proactively trying to make the 1.3.0 RM's job easier.
{quote}
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?
{quote}
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
(v6.3.4#6332)
