hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@apache.org>
Subject Re: [DISCUSS] What versions should be mentioned in CHANGES.md/RELEASENOTES.md per release?
Date Wed, 12 Jun 2019 10:37:35 GMT
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 <zghaobac@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 <apurtell@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 <stack@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 <zghaobac@gmail.com>
> > wrote:
> > > >
> > > > >>
> > > > >> We use JIRA’s change log generation feature instead.
> > > > >>
> > > > > Do we have any document about this?
> > > > >
> > > > > Andrew Purtell <andrew.purtell@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 <zghaobac@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) <palomino219@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.purtell@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 <stack@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
<stack@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message