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] Consider truncating CHANGES.md files on new release branches
Date Tue, 10 Nov 2020 11:37:15 GMT
I thought we had written up a guide before for what goes in the changes
file, but I can't find it at the moment.

For branch 2.3 I am surprised at 0.99 stuff. I would expect:

* 2.0.0
* 2.1.0
* 2.2.0
* 2.3.[0-z]

Because that would be enough that if I was coming from the prior major
release I could see everything that might matter getting to the release.

If we just include 2.3.z changes then I have to go look at each of the
previous minor releases on the release line as well.

We've talked for some time about possibly including release notes / changes
for just those things in each individual release on the website before.
Would adding something like that be sufficient for the use you're thinking
of?




On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <ndimiduk@apache.org> wrote:

> Heya,
>
> The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big for
> Github to render. Its content covers back to 0.99. This isn't really usable
> by someone who wants to easily see what's new in the latest patch release.
>
> I propose we truncate these changes files to what's new for the release
> branch. It probably needs some more work, but the git-jira audit script [0]
> is able to generate a report of what's new (never previously released) for
> a target release-line branch. We could use this as the basis for the
> CHANGES file when starting a new release-line branch. From then on, Yetus
> takes care of the patch release updates.
>
> What do you think?
>
> Thanks,
> Nick
>
> [0]:
>
> https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
>

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