Investigate automation of publishing new npm versions

[mhdawson]

Seems like after a PR to update is reviewed/landed we could automate publishing a new version.

[KevinEady]

I can take a look at this.

I am wondering about what we should do with the versioning of our package? Should it match the Node.js version the headers are based on? For example, after merging #40 , we would publish this package as version 22.1.0? I think we had this discussion before but not sure the outcome (if there was one)?

If we don't go with that, what would our versioning scheme be -- just update the minor version every time? From a solution standpoint, this is much easier 😄

What are your thoughts @NickNaso ?

[NickNaso]

Hi @KevinEady you are right and we decided to follow the rules reported in the section Version of the docs https://github.com/nodejs/node-api-headers?tab=readme-ov-file#versions. I think that is the simpler thing that we can do.

[KevinEady]

Hi @NickNaso ,

So I see the (semi-)automated release flow going like so:

• Create new workflow (prepare-release) that:

  • triggers only on main with changes in ['def/*', 'include/*']
  • updates package version via npm version minor
  • updates CHANGELOG.md with the notable changes and commits list since last release tag
  • creates branch release/v<version>
  • commits changes with commit message release: v<version>
  • creates PR with title release: v<version> and body Automated release for version v<version>

• Create new workflow (publish-release) that:

  • triggers only on main with changes in package.json
  • runs only if package version is not published on npm
  • runs npm publish
  • creates and pushes tag v<version>
  • creates a GitHub Release for new tag with "Whats Changed" as a list of all commits since tag of last published version

I would not want a 100% automatic publishing process, and so this above CI flow would require only one manual step for the release: approving the PR with the version change created by prepare-release. This gives us a chance to make any changes as needed (eg. updating READMEs, adding contributors, ...) before the final publish. Also due to branch protection, we can't write directly into main, which is why some PR must exist.

I am also tempted to not have the publish-release workflow be automatic, and require running the action manually.

Thoughts on all of this?

[NickNaso]

Hi @KevinEady, I agree with you maybe we should trigger the publish-release workflow only when a branch release/v<version> is merged or manually.