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 <[email protected]> wrote: >> >> We use JIRA’s change log generation feature instead. >> > Do we have any document about this? > > Andrew Purtell <[email protected]> 于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 <[email protected]> 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) <[email protected]> 于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 <[email protected]> 于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 <[email protected]> wrote: >>>>>>> >>>>>>> On Mon, Jun 10, 2019 at 8:05 AM Sean Busbey <[email protected]> >>>> 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 <[email protected]> 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 >>>>>>> >>>>> >>>> >>
