> > The change log there is based on the 1.4.9 one and contains everyone later > than 1.4.9 or new to 1.5.0. > So only generate the release note of 1.5.0 and append it to 1.4.9's release note, then get a new release note for 1.5.0? If I am not wrong, the yetus use issue's fix version to generate release note. There are duplicate issues number if a issus's fix versions has both 1.4.9 and 1.5.0?
张铎(Duo Zhang) <palomino...@gmail.com> 于2019年6月11日周二 上午8:31写道： > Maybe we could add a note at the bottom of the release note for each minor > release line, to mention that this release line contains all the changes in > the previous minor or major release? > > For example, 2.1.0 contains all the changes in 2.0.0, and 2.0.0 contains > all the changes in 1.0.0. If users are interested they can go to see the > release note for the previous major or minor release line. > > Andrew Purtell <andrew.purt...@gmail.com> 于2019年6月11日周二 上午12:08写道： > > > 1.5.0 will continue the practice. The change log there is based on the > > 1.4.9 one and contains everyone later than 1.4.9 or new to 1.5.0. > > > > The branch-1 releases use the old practice of JIRA generated change logs, > > not the far more verbose Yetus ones, and even then a list of objects > > ordered by size is dominated in the largest of sizes by these auto > > generated CHANGES files, mixed in with generated protobuf and thrift > > support files. How big would a Yetus generated release notes file be if > it > > includes changes all the way back to HBASE-1? > > > > > On Jun 10, 2019, at 8:16 AM, Stack <st...@duboce.net> wrote: > > > > > >> On Mon, Jun 10, 2019 at 8:05 AM Sean Busbey <bus...@apache.org> > wrote: > > >> > > >> Back for the 1.2 release line I tried to include enough information > > >> that someone looking at the given 1.2 release coming from the prior > > >> major version would have everything. > > >> > > >> That meant: > > >> > > >> * 1.0.0 release notes > > >> * 1.1.0 release notes > > >> * 1.2.z (for all z 0-12) release notes > > >> > > >> https://github.com/apache/hbase/blob/branch-1.2/CHANGES.txt > > > > > > > > > > > > Yeah, this is how it has been in all releases until 2.1 where I seem to > > > have broken the practice (I just looked at the 1.4.10 RC and notice > that > > > Andrew follows the above practice. 2.0.x has all CHANGES). > > > > > > > > > > > >> I do not know if this was actually useful. This seems like a > > >> conversation better had on user@hbase, tbh. > > >> > > >> > > > I can ask over there too. > > > > > > > > > S > > > > > > > > > > > > > > > > > >> (folks interested in background material, the last time we talked > > >> about this was in HBASE-14025 in 2015 and 2016) > > >> > > > > > > > > > > > >>> On Mon, Jun 10, 2019 at 9:54 AM Stack <st...@duboce.net> wrote: > > >>> > > >>> I was under the impression that our CHANGES.md was a list of all > > changes > > >>> since the beginning of time but branch-2.2 only has 2.2.0 changes and > > >>> Guanghao points out that hbase-2.1 releases have CHANGES only since > > 2.1.0 > > >>> (I'm RM on branch-2.1). > > >>> > > >>> I see Sean say in another thread says > > >>> > > >>> "Historically that has meant "all the maintenance releases in this > > >> minor > > >>> release". > > >>> > > >>> (Andrew thinks we should not bundle CHANGES.md/RELEASENOTES.md but > just > > >>> point elsewhere and/or to JIRA). > > >>> > > >>> What do folks think? I think these docs should have all changes in > > them; > > >>> i.e. that branch-2.1 is doing it wrong? > > >>> > > >>> Thanks, > > >>> S > > >> > > >
