Better/more bumping flexibility for initial-development-versions, i.e. < 1.0.0.

[rklec]

It would be great to finally solve conventional-changelog#539

TL;DR

In Standard-Version when you have a version < 1.0.0 it always bumps the patch version, no matter what you do.
It would be great to be able to adjust this behavior.

The SemVer 2.0.0 spec days:
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.

However, this is only the FAQ part and a suggestion (i.e. "The simplest thing to do").

What the spec really defines is:

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.

It explicitly allows y (the minor version) to change.

The thread in semver/semver#333 (comment) tackles this issue and I guess this summarized the current state quite good:

There is nothing explicit about what the rules for initial development should be.

As such, IMHO, there should at least be a flag/configuration option in .versionrc to also bump minor in the initial development stage (<1.0.0) just like you would do when it is stable.
Otherwise the version always stays at 0.0.z until 1.0.0 which feels awkward to me and let me to find this issue as it was clearly unexpected/not what I thought standard-version would behave.

Both variants are clearly in line with the spec, so IMHO, standard-version should support it. You could even, and that may be discussed, doing that new behavior by default. Or better introduce it as optional for now and later make it a default, if you want to go that way.
BTW SemVer 2.0.0 also says:
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.

That's not the patch version (0.0.z), as Standard-Version currently does! Minor would make more, sense IMHO, but still the usual bumping behavior would be better. (0.y.0)

Idea

• The default behavior may be changed. Maybe bump the minor version? Or better use the "default behaviour" for bumping as described above.
• An entry in .versionrc where you can choose what to bump in pre-release versions like minor or patch (you can set it to patch to keep/restore the old behavior of standard-version) or auto (or maybe called default), where it chooses based on whether it's a feat(ure) or (bug) fix.

[TimothyJones]

The purpose of this tool is:

A utility for versioning using semver and CHANGELOG generation powered by Conventional Commits.

I think this is a conventional commits issue, and not an issue for this tool.

---

However, I do have some thoughts on this:

You're right that there isn't a specification-defined behaviour for versions below 1.0.0, but there is a community convention (and implementation-defined behaviour).

Specifically for npm, if your version is between 0.1.0 and 1.0.0, npm treats an update to the minor version as a breaking change - that is ^0.1.0 will match 0.1.2 but not 0.2.0.

Rust's cargo is another ecosystem which has leaned heavily into semver, and it behaves the same way.

This tool (via conventional-commits) also follows that convention - breaking changes below v1.0.0 are treated as a minor version bump. Here's an example repo I quickly put together:

$ git log --pretty=oneline --abbrev-commit
1a4994a (HEAD -> main, tag: v0.1.0) chore(release): 0.1.0
3598012 fix!: Example breaking change
9e2ba95 (tag: v0.0.2) chore(release): 0.0.2
1017b00 chore: initial commit

Given that there's a clear community convention adopted here, I'm not sure it would be a positive contribution to make it easier to work with alternate conventions.

Semver's only guarantee is "all bets are off", but npm has made a choice about what bets to make - and other package ecosystems do the same thing. It seems dangerous to have automated tooling allow other interpretations.

As an aside - if you're making good commit messages that can be read by this tool, then what's the harm in starting at v1.0.0? If you're tracking breaking changes / features etc via your commits, you're almost certainly past "initial development".

[TimothyJones]

I'm going to close this for now, please reopen if you'd like to discuss this more.

[TimothyJones]

I've added some additional discussion here to describe the fork rationale: #30

[sbboli]

@TimothyJones I feel not everyone is necessarily developing "packages" but other software projects such as websites, that are not consumed and relied on like "packages". I mean, is there even such a think like a "breaking change" on a web-frontend? We are currently working towards a first release (1.0.0) for a web-project, and it would be nice to properly keep track of new features and bugfixes till then. While I understand that that convetion makes sense in the world of "package" development, it doesn't neccessarily in other contexts.

I actually expected the preMajor flag to solve that. I tried to bump after a feature commit from 0.1.0 with --preMajor false, but it still just bumped the patch.

Considering the laid out scenario, any chance to cover those other use-cases as well?

[TimothyJones]

are not consumed and relied on like "packages"

Hmm. I don't think semver is for this usecase, though. The spec says:

Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it SHOULD be precise and comprehensive.

Anyway, could you elaborate on what you mean by "properly keep track of new features and bugfixes til then"? You should be able to track those fine, but what will happen before 1.0.0 is just that the minor version will bump for breaking changes, and the patch version will bump for everything else. As discussed above, this is by convention.

I actually expected the preMajor flag to solve that.

I'm not familiar with this flag. Where did you find it documented / defined?

Considering the laid out scenario, any chance to cover those other use-cases as well?

As above, I don't think it's appropriate to directly cover non-semver or unconventional use-cases. However, if you want to override the version number generation, you can use --release-as to release whatever you like.