[jira] [Commented] (HBASE-18828) [2.0] Generate CHANGES.txt

["stack (JIRA)" <ji...@apache.org>]

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

stack commented on HBASE-18828:
-------------------------------

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 <en...@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)