-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better/more bumping flexibility for initial-development-versions, i.e. < 1.0.0. #26
Comments
The purpose of this tool is:
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, 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:
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". |
I'm going to close this for now, please reopen if you'd like to discuss this more. |
I've added some additional discussion here to describe the fork rationale: #30 |
@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 Considering the laid out scenario, any chance to cover those other use-cases as well? |
Hmm. I don't think semver is for this usecase, though. The spec says:
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'm not familiar with this flag. Where did you find it documented / defined?
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 |
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.
Idea
.versionrc
where you can choose what to bump in pre-release versions likeminor
orpatch
(you can set it topatch
to keep/restore the old behavior of standard-version) orauto
(or maybe calleddefault
), where it chooses based on whether it's afeat
(ure) or (bug)fix
.The text was updated successfully, but these errors were encountered: