[
https://issues.apache.org/jira/browse/HBASE-18828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16427973#comment-16427973
]
stack edited comment on HBASE-18828 at 4/6/18 5:09 AM:
-------------------------------------------------------
Ok. Lets use yetus `releasedocmaker` going forward from hbase-2.0.0
(HBASE-14175). I'll check in its generated RELEASENOTES.md and CHANGELOG.md in
place of CHANGES.txt. `releasedocmaker` presumes JIRA is up to date and is
'source of truth'.
I just did a pass through JIRA doing fixup on fixVersion making its content
agree with what is in git and vice version.
Here is how I did this "...validating the fix versions set in JIRA": I copied
and pasted Sean's recipe from HBASE-14025 and updated it using 2.0.0 RC as
version and changed instruction so they were focused on a major release.
Of note, we branched 2.0.0 a long-time ago (4 years ago), at this point:
{code}
commit 0167558eb31ff48308d592ef70b6d005ba6d21fb
Author: Enis Soztutar <e...@apache.org>
Date: Mon Jun 30 20:11:02 2014 -0700
HBASE-11448 Fix javadoc warnings
{code}
The next commit was {{92c52a727a Updated version in master to 2.0.0-SNAPSHOT
after 'branch-1' is created for 1.x line of releases}}. We are talking 0.94-ish
time.
The releasedocmaker tool is in yetus. You need to download it.. See note at the
bottom of yetus' downloads page for how to do a homebrew install on your Mac
(via [~busbey]) as well as his suggestion that we rely on released versions of
yetus).
# Clean up JIRA for your release
## Get the {{CHANGELOG.md}} and {{RELEASENOTES.md}} from JIRA via the
releasedocmaker tool; i.e. for 2.0.0: {code}$
./release-doc-maker/releasedocmaker.py -p HBASE --fileversions -v 2.0.0{code}.
It is also possible to do release docs across a range of versions; pass {code}
--range --version START_VERSION --version END_VERSION{code}
## Filter the produced {{CHANGELOG.md}} so we have just a list of JIRA IDs
{code}$ cat CHANGELOG.md | grep -o -E "\[HBASE-[0-9]*\]" | grep -o -E
"HBASE-[0-9]*" | sort -u > CHANGELOG_jiras.txt{code}
## Get the set of JIRAs that are marked in git.
### Find the commit where your release line branched off from the previous
release. {code}$ git merge-base origin/branch-1 origin/branch-2.0
0167558eb31ff48308d592ef70b6d005ba6d21fb{code:java}
### Get the set of all jiras committed between that branch point and current
branch tip (this is a deviation from Sean recipe. This is major version so all
changes since branch for previous major version). {code}$ git log --oneline
0167558eb31ff48308d592ef70b6d005ba6d21fb...3ee8b0c75b | grep -o -E
"^[0-9a-z]*\s*HBASE-[0-9]*"|awk '{print $2}' | sort -u > in_git_2.0.0.txt{code}
## Go through JIRAs that appear in the JIRA tracker but not in git {code}$ comm
-1 -3 in_git_2.0.0.txt CHANGELOG_jiras.txt{code}.
## * The commits may be in git but committed BEFORE the branch was made for
this release. Do not include these as part of this release.
## * Sometimes the format of the commit line is wrong (adjust your grep above
accordingly -- e.g. some committers add a '.' or a ':' after the JIRA ID).
##* sometimes these are issues that didn't get properly cleaned up when things
made it into the previous minor/major release during the RC process
##* sometimes they're task or umbrella jiras that don't have a representation
in git
##* sometimes they're documentation jiras that shouldn't have been marked for
the release (doc tickets always are resolved against the major version that was
in the _master_ git branch at the time)
##* sometimes they're improperly closed tickets (e.g. invalid, duplicate, and
wontfix tickets should not have a fix version)
##* sometimes they were improperly labeled on commit and weren't reverted and
reapplied with the correct commit message.
##* occasionally they're changes that should be in your branch but were missed.
in this case reopen the ticket and cherry-pick to your branch
## go through JIRAs that appear in git but not in JIRA {code}$ comm -2 -3
CHANGES_1.2.0_git.txt CHANGES_1.2.0_jira.txt {code}
##
*** sometimes these were improperly labeled on commit. ideally they will have
been reverted and reapplied with the correct commit message.
*** sometimes they weren't marked correctly in jira because they were pushed
out of the previous minor/major release during the RC process.
# remove entries in CHANGES.txt unrelated to your current release
** for a PATCH release, you should be starting from a file that only contains
related changes
** for a MINOR release, you should reset the file so that you will only have
changes for prior minor releases in the same major release (e.g. for the 1.2.0
release CHANGES.txt will start by copying the notes from 1.0.0 and 1.1.0)
** for a MAJOR release, you should reset the file so that you will only have
changes for prior major releases (e.g. for the 2.0.0 release CHANGES.txt will
start by copying the notes from 1.0.0)
# generate a post-clean-up set of text release notes from JIRA and add it to
the top of the CHANGES.txt file with the current date.
was (Author: stack):
Ok. Lets use yetus `releasedocmaker` going forward from hbase-2.0.0
(HBASE-14175). I'll check in its generated RELEASENOTES.md and CHANGELOG.md in
place of CHANGES.txt. `releasedocmaker` presumes JIRA is up to date and is
'source of truth'.
Here is how I did the "...validating the fix versions set in JIRA" suggested
over in HBASE-14025 with `releasedocmaker`. I copied and pasted Sean's recipe
from HBASE-14025 and updated it using 2.0.0 RC as version and amended
instruction so they fit making a major release rather than a point release as
HBASE-14025 details.
Of note, we branched 2.0.0 a long-time ago (4 years ago), at this point:
{code}
commit 0167558eb31ff48308d592ef70b6d005ba6d21fb
Author: Enis Soztutar <e...@apache.org>
Date: Mon Jun 30 20:11:02 2014 -0700
HBASE-11448 Fix javadoc warnings
{code}
Next commit was {{92c52a727a Updated version in master to 2.0.0-SNAPSHOT after
'branch-1' is created for 1.x line of releases}}
Requires yetus install. See note at the bottom of yetus' downloads page for how
to do a homebrew install on your Mac (via [~busbey]) as well as his suggestion
that we rely on released versions of yetus.
# Clean up JIRA for your release
## Get the {{CHANGELOG.md}} and {{RELEASENOTES.md}} from JIRA; i.e. for 2.0.0:
{code}$ ./release-doc-maker/releasedocmaker.py -p HBASE --fileversions -v
2.0.0{code}. It is also possible to do release docs across a range of versions;
pass {code} --range --version START_VERSION --version END_VERSION{code}
## Filter the produced {{CHANGELOG.md}} so just a list of JIRA IDs {code}$ cat
CHANGELOG.md | grep -o -E "\[HBASE-[0-9]*\]" | grep -o -E "HBASE-[0-9]*" | sort
-u > CHANGELOG_jiras.txt{code}
## Get the set of JIRAs that are marked in git
### Find the commit where your release line branched off from the previous
release. {code}$ git merge-base origin/branch-1 origin/branch-2.0
0167558eb31ff48308d592ef70b6d005ba6d21fb{code:java}
### Get the set of all jiras committed between that branch point and current
branch tip (this is a deviation from Sean recipe. This is major version so all
changes since branch for previous major version). {code}$ git log --oneline
0167558eb31ff48308d592ef70b6d005ba6d21fb...3ee8b0c75b | grep -o -E
"^[0-9a-z]*\s*HBASE-[0-9]*"|awk '{print $2}' | sort -u > in_git_2.0.0.txt{code}
## Go through JIRAs that appear in the JIRA tracker but not in git {code}$ comm
-1 -3 in_git_2.0.0.txt CHANGELOG_jiras.txt{code}.
## * The commits may be in git but committed BEFORE the branch was made for
this release. Do not include these as part of this release.
## * Sometimes the format of the commit line is wrong (adjust your grep above
accordingly -- e.g. some committers add a '.' or a ':' after the JIRA ID).
##* sometimes these are issues that didn't get properly cleaned up when things
made it into the previous minor/major release during the RC process
##* sometimes they're task or umbrella jiras that don't have a representation
in git
##* sometimes they're documentation jiras that shouldn't have been marked for
the release (doc tickets always are resolved against the major version that was
in the _master_ git branch at the time)
##* sometimes they're improperly closed tickets (e.g. invalid, duplicate, and
wontfix tickets should not have a fix version)
##* sometimes they were improperly labeled on commit and weren't reverted and
reapplied with the correct commit message.
##* occasionally they're changes that should be in your branch but were missed.
in this case reopen the ticket and cherry-pick to your branch
## go through JIRAs that appear in git but not in JIRA {code}$ comm -2 -3
CHANGES_1.2.0_git.txt CHANGES_1.2.0_jira.txt {code}
##
*** sometimes these were improperly labeled on commit. ideally they will have
been reverted and reapplied with the correct commit message.
*** sometimes they weren't marked correctly in jira because they were pushed
out of the previous minor/major release during the RC process.
# remove entries in CHANGES.txt unrelated to your current release
** for a PATCH release, you should be starting from a file that only contains
related changes
** for a MINOR release, you should reset the file so that you will only have
changes for prior minor releases in the same major release (e.g. for the 1.2.0
release CHANGES.txt will start by copying the notes from 1.0.0 and 1.1.0)
** for a MAJOR release, you should reset the file so that you will only have
changes for prior major releases (e.g. for the 2.0.0 release CHANGES.txt will
start by copying the notes from 1.0.0)
# generate a post-clean-up set of text release notes from JIRA and add it to
the top of the CHANGES.txt file with the current date.
> [2.0] Generate CHANGES.txt
> --------------------------
>
> Key: HBASE-18828
> URL: https://issues.apache.org/jira/browse/HBASE-18828
> Project: HBase
> Issue Type: Sub-task
> Reporter: stack
> Assignee: stack
> Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: changelog.md, releasenotes.md
>
>
> See [~busbey] writeup on generating CHANGES.txt here HBASE-14025 (fold it
> into refguide while at it..)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
