I thought we had written up a guide before for what goes in the changes file, but I can't find it at the moment.
For branch 2.3 I am surprised at 0.99 stuff. I would expect: * 2.0.0 * 2.1.0 * 2.2.0 * 2.3.[0-z] Because that would be enough that if I was coming from the prior major release I could see everything that might matter getting to the release. If we just include 2.3.z changes then I have to go look at each of the previous minor releases on the release line as well. We've talked for some time about possibly including release notes / changes for just those things in each individual release on the website before. Would adding something like that be sufficient for the use you're thinking of? On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <ndimi...@apache.org> wrote: > Heya, > > The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big for > Github to render. Its content covers back to 0.99. This isn't really usable > by someone who wants to easily see what's new in the latest patch release. > > I propose we truncate these changes files to what's new for the release > branch. It probably needs some more work, but the git-jira audit script [0] > is able to generate a report of what's new (never previously released) for > a target release-line branch. We could use this as the basis for the > CHANGES file when starting a new release-line branch. From then on, Yetus > takes care of the patch release updates. > > What do you think? > > Thanks, > Nick > > [0]: > > https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit >
