chore: auto release changelog

[gengjiawen]

Fix#2286

Sample PR: https://github.com/gengjiawen/node-gyp/pull/2/files. (has some bugs)

Checklist

• npm install && npm test passes
• tests are included
• documentation is changed or added
• commit message follows commit guidelines

Description of change

[gengjiawen]

@rvagg Can you accept with the new changelog styles, https://github.com/gengjiawen/node-gyp/pull/2/files. (we have to manual change the log the first time since the style conflicts， see https://github.com/google-github-actions/release-please-action/issues/231)

[rvagg]

@gengjiawen I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking. The manual change seems like quite a tedious process though!
I'm not sure what google-github-actions/release-please-action#231 is all about and whether it needs anything from me. Let me know if there's something specific.

[gengjiawen]

I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking.

Yeap. I am wondering you are okay with current format. If it's okay with you. I will move this forward.

[rvagg]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

[gengjiawen]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

This takes way much more time than I expected, but I do believe it has very long term value to improve our delivery speed 😃

[DeeDeeG]

Hi, folks. I took a look at this.

• The first hurdle I hit was that release-please-action wanted to delete the existing CHANGELOG.md contents.
  • This is fixed with a minor MarkDown formatting tweak: DeeDeeG@1ffecb8
• With that formatting change applied, release-please-action will happily create new CHANGELOG.md entries, while preserving the existing ones.
  • Problem?: The formatting it wants to use is going to look a lot different from the existing CHANGELOG.md entries.
  • Solutions?:
    • Just accept the different formatting and style from ~8.1.0 onward, not matching the style of previous CHANGELOG.md entries
    • Reformat the old entries (see @gengjiawen's PR) (Requires thought and manual intervention)
    • Look for an alternative other than release-please-action that can format things in a more "Node-like" CHANGELOG style?
      • Probably this: https://github.com/nodejs/changelog-maker

This is re-treading a lot of ground that @gengjiawen already went through, but I hope it's helpful to note what happened, and what the technical hurdles are that I'm seeing, when looking at adopting release-plesase-action.

(See "Problem?" and "Solutions?" bullets above for where I'm at with this. I prefer the existing formatting style over what release-please-action produces, personally.)

[owl-from-hogvarts]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

[aramb-dev]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

@owl-from-hogvarts I have no idea.

[aramb-dev]

I put together a quick script to echo a new CHANGELOG.md in the console, also updates the version in package.json:

https://gist.github.com/DeeDeeG/dd01f704ef3c726f6a9f08dfc533ab85

(Using changelog-maker)

This can be done in GitHub Actions so that any logged-in GitHub user could easily copy-paste the new CHANGELOG.md to draft a release PR. Expanding on that start, I don't think it would be too difficult to find some other GitHub Actions allowing an automated Pull Request to be opened, and to update that pull request's branch with the new CHANGELOG.md and updated package.json.

(This workflow could perhaps run every time a commit is pushed to master, similar to how release-please-action works)

Getting on my soapbox/personal opinion time: I like the changelog styling that already exists here, and release-please-action doesn't natively understand the Node-style prefixes such as lib:, doc:, gyp:, test: and so on. It seems to want to lump things together under categories like "features" or "bug fixes", but the Node-style prefixes don't provide that information, so it becomes all lumped under an arbitrary category like "core" in @gengjiawen's PR. (Which at first glance seems to be pretty much the best we could do, using release-please-action.) I rather think bolding the prefixes is better, like : deps:, docs:, lib:, and so on. So that's why I think to preserve the existing "Node-style" changelog formatting rather than use release-please...

I admit, however, that I was asked to look into using release-please, so I don't want to derail if that approach is still preferred. I will work on that approach if it's the way to move forward. In which case, please see my previous comment. (Specifically, if we use release-please, it would be good to know how to resolve the style difference: mixed, with release-please style going forward and old style entries preserved for previous entries, or re-write all the existing CHANGELOG entries in release-please style?)

@danbev@gengjiawen@owl-from-hogvarts@aramservices 👍

[rvagg]

fwiw I'm fine with a change of format, I don't think consistency in changelog format should be a blocker here. It'd be nice to not change older sections, but newer sections can be whatever they need to be. A changelog is just a utility for people to be able to quickly grok what's changed to figure out whether they need to care or not. As long as we're serving that purpose then we're good.

[gengjiawen]

Fix#2286

Sample PR: https://github.com/gengjiawen/node-gyp/pull/2/files. (has some bugs)

Checklist

• npm install && npm test passes
• tests are included
• documentation is changed or added
• commit message follows commit guidelines

Description of change

[gengjiawen]

@rvagg Can you accept with the new changelog styles, https://github.com/gengjiawen/node-gyp/pull/2/files. (we have to manual change the log the first time since the style conflicts， see https://github.com/google-github-actions/release-please-action/issues/231)

[rvagg]

@gengjiawen I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking. The manual change seems like quite a tedious process though!
I'm not sure what google-github-actions/release-please-action#231 is all about and whether it needs anything from me. Let me know if there's something specific.

[gengjiawen]

I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking.

Yeap. I am wondering you are okay with current format. If it's okay with you. I will move this forward.

[rvagg]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

[gengjiawen]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

This takes way much more time than I expected, but I do believe it has very long term value to improve our delivery speed 😃

[DeeDeeG]

Hi, folks. I took a look at this.

• The first hurdle I hit was that release-please-action wanted to delete the existing CHANGELOG.md contents.
  • This is fixed with a minor MarkDown formatting tweak: DeeDeeG@1ffecb8
• With that formatting change applied, release-please-action will happily create new CHANGELOG.md entries, while preserving the existing ones.
  • Problem?: The formatting it wants to use is going to look a lot different from the existing CHANGELOG.md entries.
  • Solutions?:
    • Just accept the different formatting and style from ~8.1.0 onward, not matching the style of previous CHANGELOG.md entries
    • Reformat the old entries (see @gengjiawen's PR) (Requires thought and manual intervention)
    • Look for an alternative other than release-please-action that can format things in a more "Node-like" CHANGELOG style?
      • Probably this: https://github.com/nodejs/changelog-maker

This is re-treading a lot of ground that @gengjiawen already went through, but I hope it's helpful to note what happened, and what the technical hurdles are that I'm seeing, when looking at adopting release-plesase-action.

(See "Problem?" and "Solutions?" bullets above for where I'm at with this. I prefer the existing formatting style over what release-please-action produces, personally.)

[owl-from-hogvarts]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

[aramb-dev]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

@owl-from-hogvarts I have no idea.

[aramb-dev]

I put together a quick script to echo a new CHANGELOG.md in the console, also updates the version in package.json:

https://gist.github.com/DeeDeeG/dd01f704ef3c726f6a9f08dfc533ab85

(Using changelog-maker)

This can be done in GitHub Actions so that any logged-in GitHub user could easily copy-paste the new CHANGELOG.md to draft a release PR. Expanding on that start, I don't think it would be too difficult to find some other GitHub Actions allowing an automated Pull Request to be opened, and to update that pull request's branch with the new CHANGELOG.md and updated package.json.

(This workflow could perhaps run every time a commit is pushed to master, similar to how release-please-action works)

Getting on my soapbox/personal opinion time: I like the changelog styling that already exists here, and release-please-action doesn't natively understand the Node-style prefixes such as lib:, doc:, gyp:, test: and so on. It seems to want to lump things together under categories like "features" or "bug fixes", but the Node-style prefixes don't provide that information, so it becomes all lumped under an arbitrary category like "core" in @gengjiawen's PR. (Which at first glance seems to be pretty much the best we could do, using release-please-action.) I rather think bolding the prefixes is better, like : deps:, docs:, lib:, and so on. So that's why I think to preserve the existing "Node-style" changelog formatting rather than use release-please...

I admit, however, that I was asked to look into using release-please, so I don't want to derail if that approach is still preferred. I will work on that approach if it's the way to move forward. In which case, please see my previous comment. (Specifically, if we use release-please, it would be good to know how to resolve the style difference: mixed, with release-please style going forward and old style entries preserved for previous entries, or re-write all the existing CHANGELOG entries in release-please style?)

@danbev@gengjiawen@owl-from-hogvarts@aramservices 👍

[rvagg]

fwiw I'm fine with a change of format, I don't think consistency in changelog format should be a blocker here. It'd be nice to not change older sections, but newer sections can be whatever they need to be. A changelog is just a utility for people to be able to quickly grok what's changed to figure out whether they need to care or not. As long as we're serving that purpose then we're good.

[gengjiawen]

Fix#2286

Sample PR: https://github.com/gengjiawen/node-gyp/pull/2/files. (has some bugs)

Checklist

• npm install && npm test passes
• tests are included
• documentation is changed or added
• commit message follows commit guidelines

Description of change

[gengjiawen]

@rvagg Can you accept with the new changelog styles, https://github.com/gengjiawen/node-gyp/pull/2/files. (we have to manual change the log the first time since the style conflicts， see https://github.com/google-github-actions/release-please-action/issues/231)

[rvagg]

@gengjiawen I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking. The manual change seems like quite a tedious process though!
I'm not sure what google-github-actions/release-please-action#231 is all about and whether it needs anything from me. Let me know if there's something specific.

[gengjiawen]

I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking.

Yeap. I am wondering you are okay with current format. If it's okay with you. I will move this forward.

[rvagg]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

[gengjiawen]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

This takes way much more time than I expected, but I do believe it has very long term value to improve our delivery speed 😃

[DeeDeeG]

Hi, folks. I took a look at this.

• The first hurdle I hit was that release-please-action wanted to delete the existing CHANGELOG.md contents.
  • This is fixed with a minor MarkDown formatting tweak: DeeDeeG@1ffecb8
• With that formatting change applied, release-please-action will happily create new CHANGELOG.md entries, while preserving the existing ones.
  • Problem?: The formatting it wants to use is going to look a lot different from the existing CHANGELOG.md entries.
  • Solutions?:
    • Just accept the different formatting and style from ~8.1.0 onward, not matching the style of previous CHANGELOG.md entries
    • Reformat the old entries (see @gengjiawen's PR) (Requires thought and manual intervention)
    • Look for an alternative other than release-please-action that can format things in a more "Node-like" CHANGELOG style?
      • Probably this: https://github.com/nodejs/changelog-maker

This is re-treading a lot of ground that @gengjiawen already went through, but I hope it's helpful to note what happened, and what the technical hurdles are that I'm seeing, when looking at adopting release-plesase-action.

(See "Problem?" and "Solutions?" bullets above for where I'm at with this. I prefer the existing formatting style over what release-please-action produces, personally.)

[owl-from-hogvarts]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

[aramb-dev]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

@owl-from-hogvarts I have no idea.

[aramb-dev]

I put together a quick script to echo a new CHANGELOG.md in the console, also updates the version in package.json:

https://gist.github.com/DeeDeeG/dd01f704ef3c726f6a9f08dfc533ab85

(Using changelog-maker)

This can be done in GitHub Actions so that any logged-in GitHub user could easily copy-paste the new CHANGELOG.md to draft a release PR. Expanding on that start, I don't think it would be too difficult to find some other GitHub Actions allowing an automated Pull Request to be opened, and to update that pull request's branch with the new CHANGELOG.md and updated package.json.

(This workflow could perhaps run every time a commit is pushed to master, similar to how release-please-action works)

Getting on my soapbox/personal opinion time: I like the changelog styling that already exists here, and release-please-action doesn't natively understand the Node-style prefixes such as lib:, doc:, gyp:, test: and so on. It seems to want to lump things together under categories like "features" or "bug fixes", but the Node-style prefixes don't provide that information, so it becomes all lumped under an arbitrary category like "core" in @gengjiawen's PR. (Which at first glance seems to be pretty much the best we could do, using release-please-action.) I rather think bolding the prefixes is better, like : deps:, docs:, lib:, and so on. So that's why I think to preserve the existing "Node-style" changelog formatting rather than use release-please...

I admit, however, that I was asked to look into using release-please, so I don't want to derail if that approach is still preferred. I will work on that approach if it's the way to move forward. In which case, please see my previous comment. (Specifically, if we use release-please, it would be good to know how to resolve the style difference: mixed, with release-please style going forward and old style entries preserved for previous entries, or re-write all the existing CHANGELOG entries in release-please style?)

@danbev@gengjiawen@owl-from-hogvarts@aramservices 👍

[rvagg]

fwiw I'm fine with a change of format, I don't think consistency in changelog format should be a blocker here. It'd be nice to not change older sections, but newer sections can be whatever they need to be. A changelog is just a utility for people to be able to quickly grok what's changed to figure out whether they need to care or not. As long as we're serving that purpose then we're good.

[gengjiawen]

Fix#2286

Sample PR: https://github.com/gengjiawen/node-gyp/pull/2/files. (has some bugs)

Checklist

• npm install && npm test passes
• tests are included
• documentation is changed or added
• commit message follows commit guidelines

Description of change

[gengjiawen]

@rvagg Can you accept with the new changelog styles, https://github.com/gengjiawen/node-gyp/pull/2/files. (we have to manual change the log the first time since the style conflicts， see https://github.com/google-github-actions/release-please-action/issues/231)

[rvagg]

@gengjiawen I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking. The manual change seems like quite a tedious process though!
I'm not sure what google-github-actions/release-please-action#231 is all about and whether it needs anything from me. Let me know if there's something specific.

[gengjiawen]

I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking.

Yeap. I am wondering you are okay with current format. If it's okay with you. I will move this forward.

[rvagg]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

[gengjiawen]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

This takes way much more time than I expected, but I do believe it has very long term value to improve our delivery speed 😃

[DeeDeeG]

Hi, folks. I took a look at this.

• The first hurdle I hit was that release-please-action wanted to delete the existing CHANGELOG.md contents.
  • This is fixed with a minor MarkDown formatting tweak: DeeDeeG@1ffecb8
• With that formatting change applied, release-please-action will happily create new CHANGELOG.md entries, while preserving the existing ones.
  • Problem?: The formatting it wants to use is going to look a lot different from the existing CHANGELOG.md entries.
  • Solutions?:
    • Just accept the different formatting and style from ~8.1.0 onward, not matching the style of previous CHANGELOG.md entries
    • Reformat the old entries (see @gengjiawen's PR) (Requires thought and manual intervention)
    • Look for an alternative other than release-please-action that can format things in a more "Node-like" CHANGELOG style?
      • Probably this: https://github.com/nodejs/changelog-maker

This is re-treading a lot of ground that @gengjiawen already went through, but I hope it's helpful to note what happened, and what the technical hurdles are that I'm seeing, when looking at adopting release-plesase-action.

(See "Problem?" and "Solutions?" bullets above for where I'm at with this. I prefer the existing formatting style over what release-please-action produces, personally.)

[owl-from-hogvarts]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

[aramb-dev]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

@owl-from-hogvarts I have no idea.

[aramb-dev]

I put together a quick script to echo a new CHANGELOG.md in the console, also updates the version in package.json:

https://gist.github.com/DeeDeeG/dd01f704ef3c726f6a9f08dfc533ab85

(Using changelog-maker)

This can be done in GitHub Actions so that any logged-in GitHub user could easily copy-paste the new CHANGELOG.md to draft a release PR. Expanding on that start, I don't think it would be too difficult to find some other GitHub Actions allowing an automated Pull Request to be opened, and to update that pull request's branch with the new CHANGELOG.md and updated package.json.

(This workflow could perhaps run every time a commit is pushed to master, similar to how release-please-action works)

Getting on my soapbox/personal opinion time: I like the changelog styling that already exists here, and release-please-action doesn't natively understand the Node-style prefixes such as lib:, doc:, gyp:, test: and so on. It seems to want to lump things together under categories like "features" or "bug fixes", but the Node-style prefixes don't provide that information, so it becomes all lumped under an arbitrary category like "core" in @gengjiawen's PR. (Which at first glance seems to be pretty much the best we could do, using release-please-action.) I rather think bolding the prefixes is better, like : deps:, docs:, lib:, and so on. So that's why I think to preserve the existing "Node-style" changelog formatting rather than use release-please...

I admit, however, that I was asked to look into using release-please, so I don't want to derail if that approach is still preferred. I will work on that approach if it's the way to move forward. In which case, please see my previous comment. (Specifically, if we use release-please, it would be good to know how to resolve the style difference: mixed, with release-please style going forward and old style entries preserved for previous entries, or re-write all the existing CHANGELOG entries in release-please style?)

@danbev@gengjiawen@owl-from-hogvarts@aramservices 👍

[rvagg]

fwiw I'm fine with a change of format, I don't think consistency in changelog format should be a blocker here. It'd be nice to not change older sections, but newer sections can be whatever they need to be. A changelog is just a utility for people to be able to quickly grok what's changed to figure out whether they need to care or not. As long as we're serving that purpose then we're good.

[gengjiawen]

Fix#2286

Sample PR: https://github.com/gengjiawen/node-gyp/pull/2/files. (has some bugs)

Checklist

• npm install && npm test passes
• tests are included
• documentation is changed or added
• commit message follows commit guidelines

Description of change

[gengjiawen]

@rvagg Can you accept with the new changelog styles, https://github.com/gengjiawen/node-gyp/pull/2/files. (we have to manual change the log the first time since the style conflicts， see https://github.com/google-github-actions/release-please-action/issues/231)

[rvagg]

@gengjiawen I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking. The manual change seems like quite a tedious process though!
I'm not sure what google-github-actions/release-please-action#231 is all about and whether it needs anything from me. Let me know if there's something specific.

[gengjiawen]

I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking.

Yeap. I am wondering you are okay with current format. If it's okay with you. I will move this forward.

[rvagg]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

[gengjiawen]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

This takes way much more time than I expected, but I do believe it has very long term value to improve our delivery speed 😃

[DeeDeeG]

Hi, folks. I took a look at this.

• The first hurdle I hit was that release-please-action wanted to delete the existing CHANGELOG.md contents.
  • This is fixed with a minor MarkDown formatting tweak: DeeDeeG@1ffecb8
• With that formatting change applied, release-please-action will happily create new CHANGELOG.md entries, while preserving the existing ones.
  • Problem?: The formatting it wants to use is going to look a lot different from the existing CHANGELOG.md entries.
  • Solutions?:
    • Just accept the different formatting and style from ~8.1.0 onward, not matching the style of previous CHANGELOG.md entries
    • Reformat the old entries (see @gengjiawen's PR) (Requires thought and manual intervention)
    • Look for an alternative other than release-please-action that can format things in a more "Node-like" CHANGELOG style?
      • Probably this: https://github.com/nodejs/changelog-maker

This is re-treading a lot of ground that @gengjiawen already went through, but I hope it's helpful to note what happened, and what the technical hurdles are that I'm seeing, when looking at adopting release-plesase-action.

(See "Problem?" and "Solutions?" bullets above for where I'm at with this. I prefer the existing formatting style over what release-please-action produces, personally.)

[owl-from-hogvarts]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

[aramb-dev]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

@owl-from-hogvarts I have no idea.

[aramb-dev]

I put together a quick script to echo a new CHANGELOG.md in the console, also updates the version in package.json:

https://gist.github.com/DeeDeeG/dd01f704ef3c726f6a9f08dfc533ab85

(Using changelog-maker)

This can be done in GitHub Actions so that any logged-in GitHub user could easily copy-paste the new CHANGELOG.md to draft a release PR. Expanding on that start, I don't think it would be too difficult to find some other GitHub Actions allowing an automated Pull Request to be opened, and to update that pull request's branch with the new CHANGELOG.md and updated package.json.

(This workflow could perhaps run every time a commit is pushed to master, similar to how release-please-action works)

Getting on my soapbox/personal opinion time: I like the changelog styling that already exists here, and release-please-action doesn't natively understand the Node-style prefixes such as lib:, doc:, gyp:, test: and so on. It seems to want to lump things together under categories like "features" or "bug fixes", but the Node-style prefixes don't provide that information, so it becomes all lumped under an arbitrary category like "core" in @gengjiawen's PR. (Which at first glance seems to be pretty much the best we could do, using release-please-action.) I rather think bolding the prefixes is better, like : deps:, docs:, lib:, and so on. So that's why I think to preserve the existing "Node-style" changelog formatting rather than use release-please...

I admit, however, that I was asked to look into using release-please, so I don't want to derail if that approach is still preferred. I will work on that approach if it's the way to move forward. In which case, please see my previous comment. (Specifically, if we use release-please, it would be good to know how to resolve the style difference: mixed, with release-please style going forward and old style entries preserved for previous entries, or re-write all the existing CHANGELOG entries in release-please style?)

@danbev@gengjiawen@owl-from-hogvarts@aramservices 👍

[rvagg]

fwiw I'm fine with a change of format, I don't think consistency in changelog format should be a blocker here. It'd be nice to not change older sections, but newer sections can be whatever they need to be. A changelog is just a utility for people to be able to quickly grok what's changed to figure out whether they need to care or not. As long as we're serving that purpose then we're good.

[gengjiawen]

Fix#2286

Sample PR: https://github.com/gengjiawen/node-gyp/pull/2/files. (has some bugs)

Checklist

• npm install && npm test passes
• tests are included
• documentation is changed or added
• commit message follows commit guidelines

Description of change

[gengjiawen]

@rvagg Can you accept with the new changelog styles, https://github.com/gengjiawen/node-gyp/pull/2/files. (we have to manual change the log the first time since the style conflicts， see https://github.com/google-github-actions/release-please-action/issues/231)

[rvagg]

@gengjiawen I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking. The manual change seems like quite a tedious process though!
I'm not sure what google-github-actions/release-please-action#231 is all about and whether it needs anything from me. Let me know if there's something specific.

[gengjiawen]

I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking.

Yeap. I am wondering you are okay with current format. If it's okay with you. I will move this forward.

[rvagg]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

[gengjiawen]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

This takes way much more time than I expected, but I do believe it has very long term value to improve our delivery speed 😃

[DeeDeeG]

Hi, folks. I took a look at this.

• The first hurdle I hit was that release-please-action wanted to delete the existing CHANGELOG.md contents.
  • This is fixed with a minor MarkDown formatting tweak: DeeDeeG@1ffecb8
• With that formatting change applied, release-please-action will happily create new CHANGELOG.md entries, while preserving the existing ones.
  • Problem?: The formatting it wants to use is going to look a lot different from the existing CHANGELOG.md entries.
  • Solutions?:
    • Just accept the different formatting and style from ~8.1.0 onward, not matching the style of previous CHANGELOG.md entries
    • Reformat the old entries (see @gengjiawen's PR) (Requires thought and manual intervention)
    • Look for an alternative other than release-please-action that can format things in a more "Node-like" CHANGELOG style?
      • Probably this: https://github.com/nodejs/changelog-maker

This is re-treading a lot of ground that @gengjiawen already went through, but I hope it's helpful to note what happened, and what the technical hurdles are that I'm seeing, when looking at adopting release-plesase-action.

(See "Problem?" and "Solutions?" bullets above for where I'm at with this. I prefer the existing formatting style over what release-please-action produces, personally.)

[owl-from-hogvarts]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

[aramb-dev]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

@owl-from-hogvarts I have no idea.

[aramb-dev]

I put together a quick script to echo a new CHANGELOG.md in the console, also updates the version in package.json:

https://gist.github.com/DeeDeeG/dd01f704ef3c726f6a9f08dfc533ab85

(Using changelog-maker)

This can be done in GitHub Actions so that any logged-in GitHub user could easily copy-paste the new CHANGELOG.md to draft a release PR. Expanding on that start, I don't think it would be too difficult to find some other GitHub Actions allowing an automated Pull Request to be opened, and to update that pull request's branch with the new CHANGELOG.md and updated package.json.

(This workflow could perhaps run every time a commit is pushed to master, similar to how release-please-action works)

Getting on my soapbox/personal opinion time: I like the changelog styling that already exists here, and release-please-action doesn't natively understand the Node-style prefixes such as lib:, doc:, gyp:, test: and so on. It seems to want to lump things together under categories like "features" or "bug fixes", but the Node-style prefixes don't provide that information, so it becomes all lumped under an arbitrary category like "core" in @gengjiawen's PR. (Which at first glance seems to be pretty much the best we could do, using release-please-action.) I rather think bolding the prefixes is better, like : deps:, docs:, lib:, and so on. So that's why I think to preserve the existing "Node-style" changelog formatting rather than use release-please...

I admit, however, that I was asked to look into using release-please, so I don't want to derail if that approach is still preferred. I will work on that approach if it's the way to move forward. In which case, please see my previous comment. (Specifically, if we use release-please, it would be good to know how to resolve the style difference: mixed, with release-please style going forward and old style entries preserved for previous entries, or re-write all the existing CHANGELOG entries in release-please style?)

@danbev@gengjiawen@owl-from-hogvarts@aramservices 👍

[rvagg]

fwiw I'm fine with a change of format, I don't think consistency in changelog format should be a blocker here. It'd be nice to not change older sections, but newer sections can be whatever they need to be. A changelog is just a utility for people to be able to quickly grok what's changed to figure out whether they need to care or not. As long as we're serving that purpose then we're good.

[gengjiawen]

Fix#2286

Sample PR: https://github.com/gengjiawen/node-gyp/pull/2/files. (has some bugs)

Checklist

• npm install && npm test passes
• tests are included
• documentation is changed or added
• commit message follows commit guidelines

Description of change

[gengjiawen]

@rvagg Can you accept with the new changelog styles, https://github.com/gengjiawen/node-gyp/pull/2/files. (we have to manual change the log the first time since the style conflicts， see https://github.com/google-github-actions/release-please-action/issues/231)

[rvagg]

@gengjiawen I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking. The manual change seems like quite a tedious process though!
I'm not sure what google-github-actions/release-please-action#231 is all about and whether it needs anything from me. Let me know if there's something specific.

[gengjiawen]

I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking.

Yeap. I am wondering you are okay with current format. If it's okay with you. I will move this forward.

[rvagg]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

[gengjiawen]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

This takes way much more time than I expected, but I do believe it has very long term value to improve our delivery speed 😃

[DeeDeeG]

Hi, folks. I took a look at this.

• The first hurdle I hit was that release-please-action wanted to delete the existing CHANGELOG.md contents.
  • This is fixed with a minor MarkDown formatting tweak: DeeDeeG@1ffecb8
• With that formatting change applied, release-please-action will happily create new CHANGELOG.md entries, while preserving the existing ones.
  • Problem?: The formatting it wants to use is going to look a lot different from the existing CHANGELOG.md entries.
  • Solutions?:
    • Just accept the different formatting and style from ~8.1.0 onward, not matching the style of previous CHANGELOG.md entries
    • Reformat the old entries (see @gengjiawen's PR) (Requires thought and manual intervention)
    • Look for an alternative other than release-please-action that can format things in a more "Node-like" CHANGELOG style?
      • Probably this: https://github.com/nodejs/changelog-maker

This is re-treading a lot of ground that @gengjiawen already went through, but I hope it's helpful to note what happened, and what the technical hurdles are that I'm seeing, when looking at adopting release-plesase-action.

(See "Problem?" and "Solutions?" bullets above for where I'm at with this. I prefer the existing formatting style over what release-please-action produces, personally.)

[owl-from-hogvarts]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

[aramb-dev]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

@owl-from-hogvarts I have no idea.

[aramb-dev]

I put together a quick script to echo a new CHANGELOG.md in the console, also updates the version in package.json:

https://gist.github.com/DeeDeeG/dd01f704ef3c726f6a9f08dfc533ab85

(Using changelog-maker)

This can be done in GitHub Actions so that any logged-in GitHub user could easily copy-paste the new CHANGELOG.md to draft a release PR. Expanding on that start, I don't think it would be too difficult to find some other GitHub Actions allowing an automated Pull Request to be opened, and to update that pull request's branch with the new CHANGELOG.md and updated package.json.

(This workflow could perhaps run every time a commit is pushed to master, similar to how release-please-action works)

Getting on my soapbox/personal opinion time: I like the changelog styling that already exists here, and release-please-action doesn't natively understand the Node-style prefixes such as lib:, doc:, gyp:, test: and so on. It seems to want to lump things together under categories like "features" or "bug fixes", but the Node-style prefixes don't provide that information, so it becomes all lumped under an arbitrary category like "core" in @gengjiawen's PR. (Which at first glance seems to be pretty much the best we could do, using release-please-action.) I rather think bolding the prefixes is better, like : deps:, docs:, lib:, and so on. So that's why I think to preserve the existing "Node-style" changelog formatting rather than use release-please...

I admit, however, that I was asked to look into using release-please, so I don't want to derail if that approach is still preferred. I will work on that approach if it's the way to move forward. In which case, please see my previous comment. (Specifically, if we use release-please, it would be good to know how to resolve the style difference: mixed, with release-please style going forward and old style entries preserved for previous entries, or re-write all the existing CHANGELOG entries in release-please style?)

@danbev@gengjiawen@owl-from-hogvarts@aramservices 👍

[rvagg]

fwiw I'm fine with a change of format, I don't think consistency in changelog format should be a blocker here. It'd be nice to not change older sections, but newer sections can be whatever they need to be. A changelog is just a utility for people to be able to quickly grok what's changed to figure out whether they need to care or not. As long as we're serving that purpose then we're good.

[gengjiawen]

Fix#2286

Sample PR: https://github.com/gengjiawen/node-gyp/pull/2/files. (has some bugs)

Checklist

• npm install && npm test passes
• tests are included
• documentation is changed or added
• commit message follows commit guidelines

Description of change

[gengjiawen]

@rvagg Can you accept with the new changelog styles, https://github.com/gengjiawen/node-gyp/pull/2/files. (we have to manual change the log the first time since the style conflicts， see https://github.com/google-github-actions/release-please-action/issues/231)

[rvagg]

@gengjiawen I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking. The manual change seems like quite a tedious process though!
I'm not sure what google-github-actions/release-please-action#231 is all about and whether it needs anything from me. Let me know if there's something specific.

[gengjiawen]

I'm not sure what needs to be done here. The format seems OK to me if that's what you're asking.

Yeap. I am wondering you are okay with current format. If it's okay with you. I will move this forward.

[rvagg]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

[gengjiawen]

yes, mostly @gengjiawen I'm happy that you're enthusiastic to take this on, you have my blessing!

This takes way much more time than I expected, but I do believe it has very long term value to improve our delivery speed 😃

[DeeDeeG]

Hi, folks. I took a look at this.

• The first hurdle I hit was that release-please-action wanted to delete the existing CHANGELOG.md contents.
  • This is fixed with a minor MarkDown formatting tweak: DeeDeeG@1ffecb8
• With that formatting change applied, release-please-action will happily create new CHANGELOG.md entries, while preserving the existing ones.
  • Problem?: The formatting it wants to use is going to look a lot different from the existing CHANGELOG.md entries.
  • Solutions?:
    • Just accept the different formatting and style from ~8.1.0 onward, not matching the style of previous CHANGELOG.md entries
    • Reformat the old entries (see @gengjiawen's PR) (Requires thought and manual intervention)
    • Look for an alternative other than release-please-action that can format things in a more "Node-like" CHANGELOG style?
      • Probably this: https://github.com/nodejs/changelog-maker

This is re-treading a lot of ground that @gengjiawen already went through, but I hope it's helpful to note what happened, and what the technical hurdles are that I'm seeing, when looking at adopting release-plesase-action.

(See "Problem?" and "Solutions?" bullets above for where I'm at with this. I prefer the existing formatting style over what release-please-action produces, personally.)

[owl-from-hogvarts]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

[aramb-dev]

@DeeDeeG can we fork and tweak release-please-action to style CHANGELOG.md as we want? Will it be too Hard?

@owl-from-hogvarts I have no idea.

[aramb-dev]

I put together a quick script to echo a new CHANGELOG.md in the console, also updates the version in package.json:

https://gist.github.com/DeeDeeG/dd01f704ef3c726f6a9f08dfc533ab85

(Using changelog-maker)

This can be done in GitHub Actions so that any logged-in GitHub user could easily copy-paste the new CHANGELOG.md to draft a release PR. Expanding on that start, I don't think it would be too difficult to find some other GitHub Actions allowing an automated Pull Request to be opened, and to update that pull request's branch with the new CHANGELOG.md and updated package.json.

(This workflow could perhaps run every time a commit is pushed to master, similar to how release-please-action works)

Getting on my soapbox/personal opinion time: I like the changelog styling that already exists here, and release-please-action doesn't natively understand the Node-style prefixes such as lib:, doc:, gyp:, test: and so on. It seems to want to lump things together under categories like "features" or "bug fixes", but the Node-style prefixes don't provide that information, so it becomes all lumped under an arbitrary category like "core" in @gengjiawen's PR. (Which at first glance seems to be pretty much the best we could do, using release-please-action.) I rather think bolding the prefixes is better, like : deps:, docs:, lib:, and so on. So that's why I think to preserve the existing "Node-style" changelog formatting rather than use release-please...

I admit, however, that I was asked to look into using release-please, so I don't want to derail if that approach is still preferred. I will work on that approach if it's the way to move forward. In which case, please see my previous comment. (Specifically, if we use release-please, it would be good to know how to resolve the style difference: mixed, with release-please style going forward and old style entries preserved for previous entries, or re-write all the existing CHANGELOG entries in release-please style?)

@danbev@gengjiawen@owl-from-hogvarts@aramservices 👍

[rvagg]

fwiw I'm fine with a change of format, I don't think consistency in changelog format should be a blocker here. It'd be nice to not change older sections, but newer sections can be whatever they need to be. A changelog is just a utility for people to be able to quickly grok what's changed to figure out whether they need to care or not. As long as we're serving that purpose then we're good.