Idea was CHANGEs.md + RELEASENOTES.md would have all changes listed, not
some subset, per Seans' text diagram. Should be accumulative. The build
scripts take care of making the new additions for you.

If the files have become large, lets add links to files that list changes
<1.0.0 and then changes between 1.0.0 and 2.0.0 on the tail of these files?

S





On Tue, Nov 10, 2020 at 3:37 AM Sean Busbey <bus...@apache.org> wrote:

> 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 <ndimi...@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
> >
>

Reply via email to