Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
+1 for restricting CHANGES.md contents with what’s new after latest release on the respective release line. On Tue, 10 Nov 2020 at 3:05 AM, Nick Dimiduk 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 >
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
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 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 >
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
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 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 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 > > >
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
On Tue, Nov 10, 2020 at 3:37 AM Sean Busbey wrote: > 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? > Having a page on the site dedicated to this would suit my needs, but maybe it's overkill if we can just "get it right" for the release tags visible on github. My objective is giving a user-friendly and self-service answer to an operator or developer asking, "why should I upgrade? / what's new in this release?" The existing CHANGES.md file on the release tag would work, except that the markdown doesn't render on Github due to size. On Mon, Nov 9, 2020, 15:35 Nick Dimiduk 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 > > >
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
+1 on what Sean proposed to include the changes started from the first major release. Sean Busbey 于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 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 > > >
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
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. 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) wrote: > +1 on what Sean proposed to include the changes started from the first > major release. > > Sean Busbey 于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 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 > > > > > >
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk 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) > wrote: > > > +1 on what Sean proposed to include the changes started from the first > > major release. > > > > Sean Busbey 于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 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 > > > > > > > > > >
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
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 wrote: > On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk 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) > > wrote: > > > > > +1 on what Sean proposed to include the changes started from the first > > > major release. > > > > > > Sean Busbey 于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 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
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
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 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 wrote: >> On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk 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) >> > wrote: >> > >> > > +1 on what Sean proposed to include the changes started from the first >> > > major release. >> > > >> > > Sean Busbey 于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 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
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
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 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 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 wrote: > >> On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk > 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) > >> > wrote: > >> > > >> > > +1 on what Sean proposed to include the changes started from the > first > >> > > major release. > >> > > > >> > > Sean Busbey 于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 > 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]: > >>
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
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 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 > 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 > 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 wrote: > > >> On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk > > 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 于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 > > 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 thes
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
On Tue, Dec 1, 2020 at 12:16 PM Andrew Purtell 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 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 > > 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 > > 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 wrote: > > > >> On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk > > > 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 于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 > >
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Like this? https://gist.github.com/apurtell/f5959f36b0b13d5e92f35b22549020cc On Wed, Dec 2, 2020 at 10:04 AM Nick Dimiduk wrote: > On Tue, Dec 1, 2020 at 12:16 PM Andrew Purtell > 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 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 >> > 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 >> > 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 wrote: >> > > >> On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk > > >> > > 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 于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. >> > > >> > > > >> > > >> > > >
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
On Wed, Dec 2, 2020 at 11:16 AM Andrew Purtell wrote: > Like this? > > https://gist.github.com/apurtell/f5959f36b0b13d5e92f35b22549020cc > > > Looks good to me. 2.3.0 CHANGELOG doesn't display because it is too big -- it is an accumulation of all changes up to 2.3 (good IMO) whereas 2.2+2.1, etc. are just the changes in those releases versus the previous version -- but you can view the 'raw version' of the 2.3 doc which is good enough I think. S > On Wed, Dec 2, 2020 at 10:04 AM Nick Dimiduk wrote: > > > On Tue, Dec 1, 2020 at 12:16 PM Andrew Purtell > > 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 > 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 > >> > 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 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 于2020年11月10日周二 下午7:37写道： > >> > > >> > > > >> > > >> > > > I thought we had written up a guide before for what goes in > >> the > >>
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
On Wed, Dec 2, 2020 at 11:16 AM Andrew Purtell wrote: > Like this? > > https://gist.github.com/apurtell/f5959f36b0b13d5e92f35b22549020cc > +1 ! On Wed, Dec 2, 2020 at 10:04 AM Nick Dimiduk wrote: > >> On Tue, Dec 1, 2020 at 12:16 PM Andrew Purtell >> 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 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 >> > >>> > 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 >>> > 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 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 于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 m
