Skip to content

Commit bc6f792

Browse files
committed
docs: Add note about pre-v1 breaking changes
1 parent e90eee0 commit bc6f792

File tree

1 file changed

+26
-0
lines changed

1 file changed

+26
-0
lines changed

README.md

Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -552,6 +552,32 @@ module.exports.writeVersion = function (contents, version) {
552552
};
553553
```
554554

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+
555581
## License
556582

557583
ISC

0 commit comments

Comments
 (0)