>
> 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
>

Reply via email to