Replies: 1 comment 2 replies
-
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. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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 followsemver
with the exception of how we handle ourpre-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 inlerna/libs/core/src/lib/conventional-commits/recommend-version.ts
Lines 76 to 94 in 914dd96
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 inpackage.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 waynode-semver
handles this, which means that you should be able to providefeature
updates throughpatch
releases on premajor version packages, since any version bump forminor
for premajor version packages are considered as potentially containing breaking and can't automatically be bumped bynpm
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.
Beta Was this translation helpful? Give feedback.
All reactions