Auto bump package version number on new release

[maltejur]

Now that there is a automated npm workflow, would it be possible to automatically create a minor release on every PR merged. For example, when a new icon is added, the version gets bumped from 2.10.1 to 2.10.2 with the new icon.

[amacado]

Hello @maltejur, we need to consider multiple boundary conditions when taking about the auto bumping of package versions. We already started to talk about it in #497:

1. Not every pull request is a new release, only pull requests to master branch
2. We are using Semantic Versioning rules, so f.e. a new icon is considered a feature and will bump the minor number (not the patch number like in your example). To auto determine what the next semver release number will be we needed to introduce requirements regarding commit messages - which is in fact nearly impossible in an open source community project. If you are interested in that topic start reading here https://github.com/semantic-release/semantic-release, https://github.com/commitizen/cz-cli, https://github.com/commitizen/cz-conventional-changelog
3. Sync the git release number (tag) with npm package version. This is a little tricky, since you need to do it in the right order: First change the version in package.json and after that create the git release targeting the branch where the package.json is already changed
4. Execute the npm publish workflow as last step of the release (after package.json has changed and git tag was created)

Summarized the main challenge is to determine the next semver conform release number based on the commits done and I don't know any other way than standardized commit messages. But I'm open to different approaches! :)

[maltejur]

To auto determine what the next semver release number will be we needed to introduce requirements regarding commit messages - which is in fact nearly impossible in an open source community project.

Well at least for new icons, this repo seems to already do a pretty good job at that (every icon pr gets squashed to new icon: ...). Implementing something like semantic-release is probably still pretty hard, but I don't think that is necessary. What I think could work, is to add a workflow that runs on every commit to main and checks if the commit starts with new icon: . If that is the case

• the workflow bumps the minor version number in package.json, because we know the commit is a new feature
• npm publish gets run, releasing the new version.
• a new GitHub release gets created with the name and types of the new icon and instructions on how to install this version via npm. Something like:

Release 2.11.0

Icons

• New: icon-name (original, plain)

Installation

To install this version from npm, run
npm i devicon@2.11.0

New icon pull requests could now be directly made against main, or the commits get manually merged into main to release them.

[amacado]

[..] if the commit starts with new icon: If that is the case[..]

And what should happen when the squashed commit does not start with new icon:? How to determine a major release or a patch? When you start to rely on commit messages ("new icon:...") you need to make sure that those convetions are beeing enforced by checks (which requires additional workflows). And this does not even solve the problem of breaking changes or fixes (which are released as patch bumps). And all those scripts need to be maintained (we know how much trouble we have even with our existing scripts - just take a look at the pull request and issue history ;-)).

Don't get me wrong, I appreciate the idea of workflow automatisation, but there is a lot to consider and work needs to be done to make such a script fail-safe and helpful in real world usage. I'm speaking on experience from internal projects where we have automated such strategies.

[maltejur]

You are probably right that this approach would just produce more work instead of giving any benefit. Thanks for your opinion on this tho!