Ya'll need to study https://semver.org/; never release new features in a patch release. Should have cut 0.6.0, instead.
Discussion
Hahaha great comment 🔥
It's only from writing libraries in a professional setting for a long time:
1. If you ship new functionality in patch releases, other teams learn not to trust you after outages and other ugly surprises.
2. If you stay in 0.y.z for too long, never committing to an API, other teams will get wore down by backwards breaking changes and stkp relying on your team.
Patch releases are for patches.
Minor releases are for new functionality.
Major releases are for API commitments.
It’s actually valid semver during 0.x.x releases. https://semver.org/#spec-item-4
Technically according to spec you can do anything during 0.x.x releases but it’s common convention to push the meanings across one place so:
- 0.5.3 > 0.6.0 = major bump
- 0.5.3 > 0.5.4 = minor bump
- No way to define a patch bump
This is the convention we’ve been following since initial launch of 0.1.0.
That's not how pre 1.0.0 releases work.
Both "major" and minor ride the y in x.y.z and patch releases are always reserved for bug fixes of existing functionaliy.
"Patch version Z (x.y.Z | x > 0) MUST be incremented if only backward compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior."
"How should I deal with revisions in the 0.y.z initial development phase?
The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release."
By launching new functionality inside of patch releases, you give developers no way to fix their version constraints to a given set of functionality.