Coverage remained the same at 100.0% when pulling 6122727 on coreyfarrell:zero-mode into 387eaae on conventional-changelog:master.

npm handles versions below 1.0.0 as such that it won't download above the specified minor with the ^ operator (go ahead and test)

Because of that it's my assumption the norm below 1.0.0 is

breaking -> minor
features -> minor
fixes -> patch

and this PR should reflect that.

I disagree about features. If you specify ^1.0.0 you get non-breaking feature releases. If you specify ^0.1.0 you should also get non-breaking feature releases. That is why this PR implements zero-mode as:

breaking -> minor
features -> patch
fixes -> patch

While I can certainly understand the angle you're coming from and the spec kinda does too

Anything may change at any time.

The fact that the API is deemed unstable (aka 0.x) does not remove the specified increment.

MINOR version when you add functionality in a backwards-compatible manner

Regardless of what version you're on.

https://semver.org/#spec-item-7

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

I guess it's a POV thing

I'm looking at item 4:

4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

This indicates to me that 0.y.z do not necessarily follow strict semver rules. Specs aside the goal of this PR is to "do the right thing" for npm dependents. From https://github.com/npm/node-semver/#caret-ranges-123-025-004:

Many authors treat a 0.x version as if the x were the major "breaking-change" indicator.

Caret ranges are ideal when an author may make breaking changes between 0.2.4 and 0.3.0 releases, which is a common practice. However, it presumes that there will not be breaking changes between 0.2.4 and 0.2.5. It allows for changes that are presumed to be additive (but non-breaking), according to commonly observed practices.

If I have a component at 0.1.0 and make a feature release followed by a bug fix release, another module which depends on ^0.1.0 should get the bug fix (released as 0.1.2, not 0.2.1).

@coreyfarrell I need this functionality to, but I think the right place to implement it is here:

conventional-changelog/conventional-changelog#421

☝️ this provides the ability to provide configuration to the conventional bump logic, such that we'd treat a bump prior to the major differently; I think this should be the default behavior.

@coreyfarrell having dug into things a bit more, I think it might be easier to change the bumping logic in standard-version itself (at least for the time being).

Alternatively we could refactor https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-recommended-bump to accept context about the old version we're attempting to bump from; which do you think is a better approach?

either way, I'd like the default behavior for pre-1.x.x to be bumping the minor for BREAKING CHANGES rather than the major.

I'm not familiar enough with the conventional-changelog ecosystem to say if the refactor you mention is better or not. Modifying standard-version is definitely easier (possibly biased by my limited knowledge of everything involved).

I can modify this patch to remove the --zero-mode argument and just follow the zero-mode rules if the current version is 0.x.x (breaking changes = minor, feature or fix = patch). The intent is that standard-version -r major and standard-version -r minor will not be effected by this change, this 'zero-mode' behavior will only happen if you do not specify an -r argument. So standard-version -r major will bump from 0.x.x to 1.0.0.

What about 0.0.x, should this be handled differently as @stevemao pointed out? Technically if the current version is 0.0.1 then 0.0.2, 0.1.0 or 1.0.0 could be used for breaking changes. As is my patch will cause a bump to 0.1.0 instead of 1.0.0.

@coreyfarrell I still think this might be better fixed in conventional-changelog, it's just a bit more of a refactor than I thought, and I need to think on it a bit.