The current specification is great when you completely control all of the Public API. If instead, you also export parts of another Public API (consume or produce), you should also take into account any version changes of that consumed API when updating.
I propose the following for discussion:
Use the greater of the API changes in both yours and the exported API, as your next API change reason.
Using the exact same mechanic as currently defined:
Bug fixes not affecting the API increment the patch version -> Private Change
Backwards compatible API additions/changes increment the minor version -> Compatible Change
Backwards incompatible API changes increment the major version -> Incompatible Change
An example:
You release 1.0.0, exporting part of component X at version 5.7.11
You need to release a minor update, in the same time X has versioned to 7.11.13
Therefore to produce a compatible 1.1.0 release, you can not update you dependency on X.
If you do update your dependency on X, you must also use an Incompatible Change update mechanic in your next release, meaning version 2.0.0
Originally created by @EddieGarmon on GitHub (Mar 15, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/80
The current specification is great when you completely control all of the Public API. If instead, you also export parts of another Public API (consume or produce), you should also take into account any version changes of that consumed API when updating.
I propose the following for discussion:
Use the greater of the API changes in both yours and the exported API, as your next API change reason.
Using the exact same mechanic as currently defined:
- Bug fixes not affecting the API increment the patch version -> Private Change
- Backwards compatible API additions/changes increment the minor version -> Compatible Change
- Backwards incompatible API changes increment the major version -> Incompatible Change
An example:
- You release 1.0.0, exporting part of component X at version 5.7.11
- You need to release a minor update, in the same time X has versioned to 7.11.13
- Therefore to produce a compatible 1.1.0 release, you can not update you dependency on X.
- If you do update your dependency on X, you must also use an Incompatible Change update mechanic in your next release, meaning version 2.0.0
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @EddieGarmon on GitHub (Mar 15, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/80
The current specification is great when you completely control all of the Public API. If instead, you also export parts of another Public API (consume or produce), you should also take into account any version changes of that consumed API when updating.
I propose the following for discussion:
Use the greater of the API changes in both yours and the exported API, as your next API change reason.
Using the exact same mechanic as currently defined:
An example: