Repository: lerna/lerna

Issue #2761: [Suggestion] Initial release 0.x.y to 1.0.0 in an automated CI release
Created: 2020-11-16T10:56:03Z
Context
We are starting with a new project always with 0.1.0. Our complete release management is automated in CI (GitLab CI) together with lerna.
Current Behavior
Commiting a BREAKING CHANGE in a 0.x.y version does currently not bump up to 1.0.0.
Expected Behavior
In general, this behavior is correct and should not be changed. But I have a suggestion how to handle initial releases. We currently do this in a live product with a custom .patch (patch-package).
Possible Solution
Doing a BREAKING CHANGE commit together with an "initial release" commit header:
chore: initial release

BREAKING CHANGE: we are live!

Possible variants: https://regex101.com/r/BpyaDb/1
How does this look like in our CI:

Patches
Patch for conventional-recommended-bump: Providing a isInitialRelease boolean to bump result.
diff --git a/node_modules/conventional-recommended-bump/index.js b/node_modules/conventional-recommended-bump/index.js
index 51c8a8a..4a73559 100644
--- a/node_modules/conventional-recommended-bump/index.js
+++ b/node_modules/conventional-recommended-bump/index.js
@@ -80,6 +80,12 @@ function conventionalRecommendedBump (optionsArgument, parserOptsArgument, cbArg
 
           let result = whatBump(commits, options)
 
+          // Find a "chore: initial release" commit to allow initial releases also for 0.x.y versions
+          // See also https://regex101.com/r/BpyaDb/1
+          result.isInitialRelease = commits
+            ? commits.filter(({ header }) => /^chore[!]?(\(\w+\))?: initial release/.test(header)).length > 0
+            : false;
+
           if (result && result.level != null) {
             result.releaseType = VERSIONS[result.level]
           } else if (result == null) {
Patch for @lerna/conventional-commits: Respect isInitialRelease only when major version is 0.
diff --git a/node_modules/@lerna/conventional-commits/lib/recommend-version.js b/node_modules/@lerna/conventional-commits/lib/recommend-version.js
index f524f9d..89fb5bd 100644
--- a/node_modules/@lerna/conventional-commits/lib/recommend-version.js
+++ b/node_modules/@lerna/conventional-commits/lib/recommend-version.js
@@ -59,7 +59,7 @@ function recommendVersion(pkg, type, { changelogPreset, rootPath, tagPrefix, pre
           log.verbose(type, "increment %s by %s", pkg.version, prereleaseType);
           resolve(semver.inc(pkg.version, prereleaseType, prereleaseId));
         } else {
-          if (semver.major(pkg.version) === 0) {
+          if (semver.major(pkg.version) === 0 && !data.isInitialRelease) {
             // 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
As we do release tomorrow our new product I can not provide a PR at the moment but perhaps someone is interested in the solution.
References

conventional-changelog/conventional-changelog#239
#2150
#2325
#2739
#2766

Duplicate issue #2766: Why lerna does not bump the first major version when using conventional commits and major version is zero?
Created: 2020-11-24T21:13:45Z
Expected Behavior
Bump 0.0.1 -> 1.0.0 when making a BREAKING CHANGE commit.
Current Behavior
Does not bump the major version. Only minor and patch.
I tried to find in the docs, but i didn't find nothing that explains the behaviour. I cannot make manually the first bump of major cause I'm using Github Actions for handle this.

Closing comment (2020-12-02T09:34:39Z): I think this is a duplicate of #2761
I have prepared a .patch for this change but had not yet time to create a PR for this.