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.purt...@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 <apurt...@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 <st...@duboce.net> wrote: > >> On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk <ndimi...@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) <palomino...@gmail.com> > >> > wrote: > >> > > >> > > +1 on what Sean proposed to include the changes started from the > first > >> > > major release. > >> > > > >> > > Sean Busbey <bus...@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 <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 > >> > > > > > >> > > > > >> > > > >> > > > > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > > - A23, Crosstalk >
