Comments (4)
The proposal of the +
sign is interesting. We use conventional-commits in order to enforce alignment with SemVer, i.e. that breaking changes target a new major version, and that changes to the public API target a new minor version (details here). We also use some other types in addition to the official fix
, feat
. Particularly, we use build
for changes in external dependencies.
One limitation we found is that it's not possible to convey the level of SemVer change (other than whether it's breaking or not) when upgrading dependencies. For instance, if the upgraded dependency introduces new feature and my codebase extends a class from such dependency, then the codebase inherits a new feature and the commit implies not a patch but a minor change (in terms of your proposal, it would be build+:
instead of build:
, although CC does not allow custom signs after the type).
With feat
however, it's a different story. First, we can use a different type (such as refactor
) for cases where the public API is not affected (after all, if the change is not part of the public API, it's just an internal implementation detail). In some cases, we have used scopes to segregate portions of the codebase that do not contribute to the public API (such as tools or executable examples), and we ignore feat
commits towards those scopes. Therefore, all the feat
commits (with a scope that can contribute to the public API) are effectively minor changes for SemVer.
Using the !
operator in conjunction with other types is also helpful. Some commits (such as those of type refactor
or build
) can be breaking changes, while others (test
, ci
, style
, docs
) are never breaking.
from conventionalcommits.org.
For instance, if the upgraded dependency introduces new feature and my codebase extends a class from such dependency, then the codebase inherits a new feature and the commit implies not a patch but a minor change (...)
That is actually incorrect and it was the point I was trying to make.
Updating a dependency is a change in your private codebase, so it should ship as a patch level increment, unless you also introduce changes in your own public API. This is true both for patch-level, minor-level, and even major-level updates in your dependencies.
Semantic versioning is used to version components with a public API and a private implementation. It doesn't care about changes impacting your implementation and only cares about changes in the public API. This is because the purpose of semantic versioning is to manage "dependency hell" by conveying information to dependents on how safe it is to upgrade a dependency. This risk level depends on changes to the public API, not changes to the private implementation, hence the following rule:
Bug fixes not affecting the API increment the patch version, backward compatible API additions/changes increment the minor version, and backward incompatible API changes increment the major version.
In other words, any kind of codebase change can introduce any type of interface change, although some combinations are less probable. This means whenever you change your codebase you also need to convey information on whether your public API was changed, and whether these changes are backward compatible or not. You can use conventional commits types to either convey information on the type of change that was made to the codebase, or the interface, but it cannot do both. It's up to you to decide.
If you decide types are used to categorize interface changes, then it should align with semantic versioning terminology.
If you decide types are used to categorize product changes, then you need an additional information for the interface change type. +
/!
symbols can be used to that extend for instance. However in that case you should untie the feat
type from a minor change and explain the distinction between types and increments.
from conventionalcommits.org.
Let me join the thread with a somewhat similar problem. There was an interesting discussion at mooltiverse/nyx#315 about whether BREAKING CHANGE
or feat!:
should bump up the major part in a project version follows Semantic Versioning.
According to the Conventional Commit documentation, every breaking change should raise the version major. According to the Semantic Versioning documentation, this is not true for version 0.y.z. Quoting Semantic Versioning:
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
As @flelli rightly points out, perhaps these ambiguities are due to the meaning of the words CAN and MUST?
This still holds true, but it looks like there's a bit of confusion between the words CAN and MUST. and also what is addressed by SemVer and Conventional Commits. The two get along well, but they're not the same.
Maybe it's worth dispelling such doubts once and for all? Personally, I props for the option in SemVer that specifies that 0.y.z versions, even if they make breaking changes, do not have to conquer the major part in the version. Version 0.y.z is, after all, a place for dynamic application development, where new fiches matter more than the stability of the public API. Semantic Versioning addresses this need very well. Conventional Commits unconditionally enforces the lifting of the major part from the version for each breaking change.
It would be great if there were no doubts as I expressed in the mooltiverse/nyx#315 thread.
from conventionalcommits.org.
According to the Conventional Commit documentation, every breaking change should raise the version major
I couldn't find such wording in https://www.conventionalcommits.org/en/v1.0.0 What is said about breaking changes is:
BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning).
That text says nothing about raising the version major, only that breaking canges correlates with major changes in SemVer (thus it's compatible with not increasing the major version component in 0.x.y versions, if the versioned artifact follows both SemVer and ConventionalCommits)
from conventionalcommits.org.
Related Issues (20)
- e62041900a74d076e1462f7a3e900eb5d7a513e2 HOT 2
- Sign up
- How to configre conventional-changelog-conventionalcommits 7? HOT 1
- `feat` is contracted, most other commonly used tags are full words. HOT 9
- 6_make test.txt
- fix: navigation bar is not responsive on smaller devices HOT 1
- Delete the .idea folder HOT 1
- Decoupling from specific versioning formats (i.e. SemVer) HOT 1
- what is the recommended way to handle deprecations? HOT 2
- Request for Arabic Language Support
- How do I choose a right commit type for adding media content?
- Specification doesn't permit footers without a body HOT 2
- Support Hindi Language HOT 1
- Add clarification for description formatting
- Scheme for documentation
- Should there be (a11y) commit type? How do you address accessibility UI related changes? HOT 1
- GPG key not found HOT 2
- Bad certificate on www.conventionalcommits.org HOT 10
- Ambiguity over footer issue references
- Do we need special types for GitOps commits ?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from conventionalcommits.org.