Background

So I'm currently working on a script to partially automate and bump packages for our monorepo setup relying on lerna using independently versioned packages.
Our packages rely on conventional-commits and are trying to follow semver with the exception of how we handle our pre-major (0.y.z) version packages, in our case we are building a component library for a Design System and the "initial development" time for new component packages can be for a longer period of time due to the complexity of our organization.

What does the feature proposal resolve?

Any premajor version package with "feature" (according to conventional commits) should be possible to bump with patch but there's code in

This states in the comment that this is in accordance to semver, but the only information I found about this in semver is the FAQ suggesting "the easiest way to handle versions for premajor versions", but it does not explicitly state that all version updates should be done as minor version releases.

node-semver documentation states that "Many authors treat a 0.x version as if the x were the major "breaking-change" indicator." . By default npm install results in "^" denoted versions in package.json. The way lerna always bumps all premajor version packages as "minor" forces users reliant on premajor version packages to manually bump packages as minor if the package is in initial release state but no breaking changes were added.

In my team, we have interpreted the semver documentation in the way node-semver handles this, which means that you should be able to provide feature updates through patch releases on premajor version packages, since any version bump for minor for premajor version packages are considered as potentially containing breaking and can't automatically be bumped by npm if ^ is used.

Feature proposal

I'm proposing that there should be a way to configure how pre-major versions are handled by lerna due to this, instead of forcing all pre-major versions to be bumped as minor version releases.