I think by git tag would work. Given the URL can be different from the visible anchor text we could use an exact git sha too, if there is concern that tags might be changed either accidentally or intentionally in a way that breaks embedded links in old changelogs.
On Tue, Dec 1, 2020 at 11:57 AM Nick Dimiduk <ndimi...@apache.org> wrote: > 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 > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
