> > We use JIRA’s change log generation feature instead. > Do we have any document about this?
Andrew Purtell <andrew.purt...@gmail.com> 于2019年6月11日周二 上午10:44写道： > We don’t use Yetus to generate release notes in 1.x releases. We use > JIRA’s change log generation feature instead. There is no overlap in the > 1.5.0 release candidate changes file. I managed fix versions in JIRA for > 1.5.0 for that purpose if you recall hundreds of fix version updates a > couple of months ago for the first 1.5.0 RC as discussed on dev@ at the > time. Should be available in list archives. > > > On Jun 10, 2019, at 5:46 PM, Guanghao Zhang <zghao...@gmail.com> wrote: > > >> > >> 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 > >>>>> > >>> > >> >
