You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Investigate automation of publishing new npm versions #13
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 😄
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.
Activity
KevinEady commentedon May 8, 2024
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 commentedon May 8, 2024
Hi @KevinEady you are right and we decided to follow the rules reported in the section
Versionof 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 commentedon May 8, 2024
Hi @NickNaso ,
So I see the (semi-)automated release flow going like so:
Create new workflow (
prepare-release) that:mainwith changes in['def/*', 'include/*']npm version minorCHANGELOG.mdwith the notable changes and commits list since last release tagrelease/v<version>release: v<version>release: v<version>and bodyAutomated release for version v<version>Create new workflow (
publish-release) that:mainwith changes inpackage.jsonnpm publishv<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 intomain, which is why some PR must exist.I am also tempted to not have the
publish-releaseworkflow be automatic, and require running the action manually.Thoughts on all of this?
NickNaso commentedon May 8, 2024
Hi @KevinEady,
I agree with you maybe we should trigger the
publish-releaseworkflow only when a branchrelease/v<version>is merged or manually.legendecas commentedon Jul 9, 2024
Automation verified at #45. Thank you all for setting this up!