On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk <ndimi...@apache.org> wrote:
> So concretely, the conclusion here is that the CHANGES.md file that ships > in 2.4.0 should contain entries for 2.0.0, 2.1.0, 2.2.0, 2.3.0, and 2.4.0? > The CHANGES.md file that ships in 2.4.1 will contain all of the above, plus > entries for 2.4.1. > > And the 1.0.0 changes. Point at a 1.0.0 CHANGES.md file rather than list the 1.0.0 changes. Ditto for 2.0.0 changes. Could do pointer for older minor releases too if too many items to list... 2.1 and maybe 2.2. S > Are you sure that's what you want? That seems like more than we need. > > Thanks, > Nick > > On Tue, Nov 10, 2020 at 5:47 PM 张铎(Duo Zhang) <palomino...@gmail.com> > wrote: > > > +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 > > > > > > > > > >
