Enable pre-major version features as patch through config. (only handling breaking changes as minor)

[jchiem]

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

lerna/libs/core/src/lib/conventional-commits/recommend-version.ts

Lines 76 to 94 in 914dd96

	// According to semver, major version zero (0.y.z) is for initial
	// development. Anything MAY change at any time. The public API
	// SHOULD NOT be considered stable. The version 1.0.0 defines
	// the (initial stable) public API.
	//
	// To allow monorepos to use major version zero meaningfully,
	// the transition from 0.x to 1.x must be explicitly requested
	// by the user. Breaking changes MUST NOT automatically bump
	// the major version from 0.x to 1.x.
	//
	// The usual convention is to use semver-patch bumps for bugfix
	// releases and semver-minor for everything else, including
	// breaking changes. This matches the behavior of `^` operator
	// as implemented by `npm`.
	//
	if (releaseType === "major") {
	releaseType = "minor";
	}
	}

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.

[fahslaj]

Hi @jchiem , thank you for the suggestion. We would gladly accept a PR that add the proposed configurability in a way that is non-breaking to existing users.

[jchiem]

Sounds good, do you have any suggestions on what the naming for the option in the lerna.json should be?

I'm thinking it could be preMajorVersionBump and "fast-track" / "slow-track" where "fast-track" would be the default where each iteration bumps as minor and slow-track would be the second option for teams like my own where we are unable to fast-track all our packages to 1.0.0 in the shortest time possible.

Or perhaps have it differentiated by "semver" vs "node-semver" instead of "fast-track/slow-track" ?

I have a working prototype in a local version of a fork set up, just need to sort out adding additional tests to cover this new option.

Currently I'm passing the new option to recommendVersion function as part of the 3rd argument object, is this alright or would it be better to separate this option out from the BaseChangelogOptions ?

[fahslaj]

I think "semver" vs "node-semver" is more clear. There will need to be clear documentation of what each of these options mean in the README for the version command, as well as pointing out which one Lerna defaults to today.

Passing it into the recommendVersion function seems good. The logic for handling breaking changes with major version 0 is in that file anyway. I believe it would belong outside the BaseChangelogOptions (as in part of the & { prereleaseId?: string; buildMetadata?: string }), as I don't think this option is needed for the changelog update logic in update-changelog.ts.

Thank you for your work on this!