On Wed, Dec 2, 2020 at 11:16 AM Andrew Purtell <apurt...@apache.org> wrote:
> Like this? > > https://gist.github.com/apurtell/f5959f36b0b13d5e92f35b22549020cc > +1 ! On Wed, Dec 2, 2020 at 10:04 AM Nick Dimiduk <ndimi...@apache.org> wrote: > >> On Tue, Dec 1, 2020 at 12:16 PM Andrew Purtell <apurt...@apache.org> >> wrote: >> >>> 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. >>> >> >> A link back to the CHANGES file in GitHub of a release tag, along with >> the tag's sha at the time of link generation, would achieve my request that >> the point to a rendered version of the changes file where possible. Thank >> you! >> >> 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 >>> >> > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > - A23, Crosstalk >
