Would need to be https://archive.apache.org/dist/hbase/
in order to make sure the release would be present. On Wed, Jun 12, 2019, 04:24 Guanghao Zhang <zghao...@gmail.com> wrote: > > > > have the foot of > > CHANGES and RELEASENOTES point to hosted, > > > +1. But one question, "release dir" means > https://dist.apache.org/repos/dist/release/hbase/? > > Andrew Purtell <apurt...@apache.org> 于2019年6月12日周三 上午12:51写道： > > > > have the foot of CHANGES and RELEASENOTES point to hosted, next older > > RELEASENOTES/CHANGES hosted in our release dir > > > > +1 > > > > > > On Mon, Jun 10, 2019 at 10:05 PM Stack <st...@duboce.net> wrote: > > > > > 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 > > > > >>>>>>> > > > > >>>>> > > > > >>>> > > > > >> > > > > > > > > > > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > > - A23, Crosstalk > > >
