File tree 1 file changed +26
-0
lines changed 1 file changed +26
-0
lines changed Original file line number Diff line number Diff line change @@ -552,6 +552,32 @@ module.exports.writeVersion = function (contents, version) {
552
552
};
553
553
```
554
554
555
+ ### Why do breaking changes before 1.0.0 not trigger a 1.0.0 release?
556
+
557
+ Below 1.0.0, the semver specification doesn't give any guarantees about the
558
+ meaning of version numbers. However, with npm there is a community convention,
559
+ and implementation-defined behaviour: If your version is between 0.1.0 and
560
+ 1.0.0, npm treats an update to the minor version as a breaking change - that is
561
+ ^0.1.0 will match 0.1.2 but not 0.2.0. Rust's cargo package manager also behaves
562
+ the same way.
563
+
564
+ This tool (via conventional-commits) also follows that convention - breaking
565
+ changes below v1.0.0 are treated as a minor version bump. Here's an example
566
+ series of commits with tagged versions:
567
+
568
+ ```
569
+ 1017b00 chore: initial commit
570
+ 9e2ba95 (tag: v0.0.2) chore(release): 0.0.2
571
+ 3598012 fix!: Example breaking change
572
+ 1a4994a (tag: v0.1.0) chore(release): 0.1.0
573
+ ```
574
+
575
+ Semver's only guarantee is "all bets are off", but npm has made a choice about
576
+ what bets to make. ` commit-and-tag-version ` follows the same convention (along
577
+ with other package managers for other ecosystems).
578
+
579
+ When you are ready to release v1.0.0, add ` --release-as 1.0.0 ` to the options.
580
+
555
581
## License
556
582
557
583
ISC
You can’t perform that action at this time.
0 commit comments