HBASE-21935 tries to automate the generation of RELEASENOTES.md and CHANGES.md. It has yetus interpolates those that made the current RC (if new RC, it scrubs the old and regenerates them). It is trying to make the upkeep of RELEASENOTES and CHANGES painless.
Could do a version of what Duo (and Andy) suggest and have the foot of CHANGES and RELEASENOTES point to hosted, next older RELEASENOTES/CHANGES hosted in our release dir? (Or to JIRA). S On Mon, Jun 10, 2019 at 8:11 PM Andrew Purtell <andrew.purt...@gmail.com> wrote: > No it is just the way it’s been done on branch-1 and going back to 0.x, > long before Yetus was a thing. The practice of using Yetus for change logs > in 2.x releases is an improvement for sure. > > On Jun 10, 2019, at 8:08 PM, Guanghao Zhang <zghao...@gmail.com> wrote: > > >> > >> 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 > >>>>>>> > >>>>> > >>>> > >> >
