hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@apache.org>
Subject Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Date Tue, 01 Dec 2020 19:57:21 GMT
I am in favor of referring off to the changes files of older releases.
Would that be by git tag, or to the files in the distribution archives?

I don’t think these changes files are for marketing as such. However, I
think they are intended to be human-readable (if not for humans, then
who/what, and why?). Not having a rendered version easily discoverable is a
barrier to this goal, and shrinking the file such that it renders in GitHub
is a low-cost approach to achieve that goal.

Thanks,
Nick

On Mon, Nov 30, 2020 at 20:04 Andrew Purtell <andrew.purtell@gmail.com>
wrote:

> Unless there is an objection to the plan I described below, it will happen
> tomorrow on branch-2 in prep for RC.
>
>
> > On Nov 30, 2020, at 4:46 PM, Andrew Purtell <apurtell@apache.org> wrote:
> >
> > 
> > I'm glad I checked email before beginning the RC.
> >
> > How about this:
> >
> > CHANGES.md file that ships in 2.4.0 will contain URLs pointing to older
> CHANGES.md for 1.0.0, 2.0.0, 2.1.0, 2.2.0, 2.3.0.
> >
> > CHANGES.md file that ships with 2.4.0 will list all issues completed for
> 2.4.0
> >
> > CHANGES.md file that ships with 2.4.1 will list all issues completed for
> 2.4.0 and 2.4.1.
> >
> > etc. until 2.5.0, at which point the CHANGES.md file that ships in 2.5.0
> will contain URLs pointing to older CHANGES.md for 1.0.0, 2.0.0, 2.1.0,
> 2.2.0, 2.3.0, and 2.4.0, and will list all issues completed for 2.5.0.
> >
> > I have felt traditionally the changes file is not where we do release
> upgrade marketing.
> >
> > If the objective is giving user-friendly and self-service answers to an
> operator or developer asking, "why should I upgrade? / what's new in this
> release?", then I humbly submit we should bring back the practice of
> writing blog posts for blogs.apache.org/hbase. Speaking of which, that
> blog is in a somewhat sad state of disrepair with a lot of broken image
> links.
> >
> >
> >> On Mon, Nov 30, 2020 at 1:02 PM Stack <stack@duboce.net> wrote:
> >> On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk <ndimiduk@apache.org>
> wrote:
> >>
> >> > So concretely, the conclusion here is that the CHANGES.md file that
> ships
> >> > in 2.4.0 should contain entries for 2.0.0, 2.1.0, 2.2.0, 2.3.0, and
> 2.4.0?
> >> > The CHANGES.md file that ships in 2.4.1 will contain all of the
> above, plus
> >> > entries for 2.4.1.
> >> >
> >> >
> >> And the 1.0.0 changes.
> >>
> >> Point at a 1.0.0 CHANGES.md file rather than list the 1.0.0 changes.
> Ditto
> >> for 2.0.0 changes. Could do pointer for older minor releases too if too
> >> many items to list... 2.1 and maybe 2.2.
> >>
> >> S
> >>
> >>
> >>
> >> > Are you sure that's what you want? That seems like more than we need.
> >> >
> >> > Thanks,
> >> > Nick
> >> >
> >> > On Tue, Nov 10, 2020 at 5:47 PM 张铎(Duo Zhang) <palomino219@gmail.com>
> >> > wrote:
> >> >
> >> > > +1 on what Sean proposed to include the changes started from the
> first
> >> > > major release.
> >> > >
> >> > > Sean Busbey <busbey@apache.org> 于2020年11月10日周二 下午7:37写道:
> >> > >
> >> > > > 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
> >> > > > >
> >> > > >
> >> > >
> >> >
> >
> >
> > --
> > 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