You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Stack <st...@duboce.net> on 2019/06/10 14:53:51 UTC
[DISCUSS] What versions should be mentioned in CHANGES.md/RELEASENOTES.md
per release?
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
Re: [DISCUSS] What versions should be mentioned in
CHANGES.md/RELEASENOTES.md per release?
Posted by Stack <st...@duboce.net>.
On Tue, Jun 11, 2019 at 9:51 AM Andrew Purtell <ap...@apache.org> wrote:
> > have the foot of CHANGES and RELEASENOTES point to hosted, next older
> RELEASENOTES/CHANGES hosted in our release dir
>
> +1
>
>
I opened HBASE-22573 to implement the above. Will give it a go...
S
>
> 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.purtell@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 <zg...@gmail.com>
> wrote:
> > >
> > > >>
> > > >> We use JIRA’s change log generation feature instead.
> > > >>
> > > > Do we have any document about this?
> > > >
> > > > Andrew Purtell <an...@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 <zg...@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) <pa...@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 <an...@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 <busbey@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
>
Re: [DISCUSS] What versions should be mentioned in
CHANGES.md/RELEASENOTES.md per release?
Posted by Sean Busbey <bu...@apache.org>.
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 <zg...@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 <ap...@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.purtell@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 <zg...@gmail.com>
> > wrote:
> > > >
> > > > >>
> > > > >> We use JIRA’s change log generation feature instead.
> > > > >>
> > > > > Do we have any document about this?
> > > > >
> > > > > Andrew Purtell <an...@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 <zg...@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) <pa...@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 <an...@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 <
> busbey@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
> >
>
Re: [DISCUSS] What versions should be mentioned in
CHANGES.md/RELEASENOTES.md per release?
Posted by Guanghao Zhang <zg...@gmail.com>.
>
> 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 <ap...@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.purtell@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 <zg...@gmail.com>
> wrote:
> > >
> > > >>
> > > >> We use JIRA’s change log generation feature instead.
> > > >>
> > > > Do we have any document about this?
> > > >
> > > > Andrew Purtell <an...@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 <zg...@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) <pa...@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 <an...@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 <busbey@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
>
Re: [DISCUSS] What versions should be mentioned in
CHANGES.md/RELEASENOTES.md per release?
Posted by Andrew Purtell <ap...@apache.org>.
> 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 <an...@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 <zg...@gmail.com> wrote:
> >
> > >>
> > >> We use JIRA’s change log generation feature instead.
> > >>
> > > Do we have any document about this?
> > >
> > > Andrew Purtell <an...@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 <zg...@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) <pa...@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 <an...@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 <bu...@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
Re: [DISCUSS] What versions should be mentioned in
CHANGES.md/RELEASENOTES.md per release?
Posted by Stack <st...@duboce.net>.
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 <an...@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 <zg...@gmail.com> wrote:
>
> >>
> >> We use JIRA’s change log generation feature instead.
> >>
> > Do we have any document about this?
> >
> > Andrew Purtell <an...@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 <zg...@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) <pa...@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 <an...@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 <bu...@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
> >>>>>>>
> >>>>>
> >>>>
> >>
>
Re: [DISCUSS] What versions should be mentioned in CHANGES.md/RELEASENOTES.md per release?
Posted by Andrew Purtell <an...@gmail.com>.
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 <zg...@gmail.com> wrote:
>>
>> We use JIRA’s change log generation feature instead.
>>
> Do we have any document about this?
>
> Andrew Purtell <an...@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 <zg...@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) <pa...@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 <an...@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 <bu...@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
>>>>>>>
>>>>>
>>>>
>>
Re: [DISCUSS] What versions should be mentioned in
CHANGES.md/RELEASENOTES.md per release?
Posted by Guanghao Zhang <zg...@gmail.com>.
>
> We use JIRA’s change log generation feature instead.
>
Do we have any document about this?
Andrew Purtell <an...@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 <zg...@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) <pa...@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 <an...@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 <bu...@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
> >>>>>
> >>>
> >>
>
Re: [DISCUSS] What versions should be mentioned in CHANGES.md/RELEASENOTES.md per release?
Posted by Andrew Purtell <an...@gmail.com>.
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 <zg...@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) <pa...@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 <an...@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 <bu...@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
>>>>>
>>>
>>
Re: [DISCUSS] What versions should be mentioned in
CHANGES.md/RELEASENOTES.md per release?
Posted by Guanghao Zhang <zg...@gmail.com>.
>
> 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) <pa...@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 <an...@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 <bu...@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
> > >>
> >
>
Re: [DISCUSS] What versions should be mentioned in
CHANGES.md/RELEASENOTES.md per release?
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
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 <an...@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 <bu...@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
> >>
>
Re: [DISCUSS] What versions should be mentioned in
CHANGES.md/RELEASENOTES.md per release?
Posted by Stack <st...@duboce.net>.
On Mon, Jun 10, 2019 at 9:08 AM Andrew Purtell <an...@gmail.com>
wrote:
> ...How big would a Yetus generated release notes file be if it includes
> changes all the way back to HBASE-1?
>
RELEASENOTES.md in branch-2.0 is almost 500k.
CHANGES.md is coming up on a megabyte.
HBase 2.0 branch has the yetus generated stuff for each minor release since
2.0.0. The tail of the CHANGES.md has 1.0.0 release notes and older
(02/20/2015); i.e. 1.0.0 changes + all that made 2.0.0.
RELEASENOTES.md is new to 2.0.0.
S
>
> > On Jun 10, 2019, at 8:16 AM, Stack <st...@duboce.net> wrote:
> >
> >> On Mon, Jun 10, 2019 at 8:05 AM Sean Busbey <bu...@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
> >>
>
Re: [DISCUSS] What versions should be mentioned in CHANGES.md/RELEASENOTES.md per release?
Posted by Andrew Purtell <an...@gmail.com>.
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 <bu...@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
>>
Re: [DISCUSS] What versions should be mentioned in
CHANGES.md/RELEASENOTES.md per release?
Posted by Stack <st...@duboce.net>.
On Mon, Jun 10, 2019 at 8:05 AM Sean Busbey <bu...@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
>
Re: [DISCUSS] What versions should be mentioned in
CHANGES.md/RELEASENOTES.md per release?
Posted by Sean Busbey <bu...@apache.org>.
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
I do not know if this was actually useful. This seems like a
conversation better had on user@hbase, tbh.
(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
Re: [DISCUSS] What versions should be mentioned in
CHANGES.md/RELEASENOTES.md per release?
Posted by Josh Elser <el...@apache.org>.
Agree with Duo. I think changes in that minor release line are the most
meaningful to users without being too much of a burden for devs.
On 6/10/19 11:06 AM, 张铎(Duo Zhang) wrote:
> I prefer we include all the diffs in this minor release line in the
> CHANGES.md. For example, 2.1.1 will also contains the contents for 2.1.0.
> But I do not think it is necessary to contain all the changes from the
> beginning, it will be too large...
>
> Stack <st...@duboce.net> 于2019年6月10日周一 下午10:54写道：
>
>> 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
>>
>
Re: [DISCUSS] What versions should be mentioned in
CHANGES.md/RELEASENOTES.md per release?
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
I prefer we include all the diffs in this minor release line in the
CHANGES.md. For example, 2.1.1 will also contains the contents for 2.1.0.
But I do not think it is necessary to contain all the changes from the
beginning, it will be too large...
Stack <st...@duboce.net> 于2019年6月10日周一 下午10:54写道：
> 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
>