+1 on what Sean proposed to include the changes started from the first major release.
Sean Busbey <bus...@apache.org> 于2020年11月10日周二 下午7:37写道： > 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 > > >
