[GH-ISSUE #366] I think I see an inconsistency of semver. #4517

New Issue

GiteaMirror · 2026-06-13T12:41:52-05:00

GiteaMirror commented

2026-06-13 12:41:52 -05:00

Originally created by @colomet on GitHub (Apr 26, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/366

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

between the introduction and the summary there are some differences.

Bug fixes not affecting the API increment the patch version,
backwards compatible API additions/changes increment the minor version,
and backwards incompatible API changes increment the major version.

Originally created by @colomet on GitHub (Apr 26, 2017). Original GitHub issue: https://github.com/semver/semver/issues/366 > MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. between the introduction and the summary there are some differences. > Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.

GiteaMirror closed this issue

2026-06-13 12:41:53 -05:00

GiteaMirror commented

2026-06-13 12:41:54 -05:00

@colomet commented on GitHub (Apr 26, 2017):

what if is compatible with the api and not compatible with other code? like addons that use the code as a base and then increment an new functionality

@colomet commented on GitHub (Apr 26, 2017): what if is compatible with the api and not compatible with other code? like addons that use the code as a base and then increment an new functionality

GiteaMirror commented

2026-06-13 12:41:55 -05:00

@krzysiekpiasecki commented on GitHub (Apr 26, 2017):

You cannot break API and expects not to break addons. So if addons are not a part of your API then they must follow this API.

@krzysiekpiasecki commented on GitHub (Apr 26, 2017): You cannot break API and expects not to break addons. So if addons are not a part of your API then they must follow this API.

GiteaMirror commented

2026-06-13 12:41:56 -05:00

@colomet commented on GitHub (Apr 26, 2017):

what is a public API?

@colomet commented on GitHub (Apr 26, 2017): what is a public API?

GiteaMirror commented

2026-06-13 12:41:56 -05:00

@krzysiekpiasecki commented on GitHub (Apr 26, 2017):

Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation.

It depends on the software. How could I answer you for your question then?

@krzysiekpiasecki commented on GitHub (Apr 26, 2017): > Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. It depends on the software. How could I answer you for your question then?

GiteaMirror commented

2026-06-13 12:41:57 -05:00

@dret commented on GitHub (Apr 28, 2017):

i think part of the problem here is that APIs do not exist in a vacuum. they exist to be consumed. and they depend on how they are consumed. hence it is critically important that consumption is well-defined, meaning that consumers must follow consumption rules. i call this "processing model" because it refers to how API consumers MUST process things. to me, any API not having a processing model is heading for trouble. here is a brief piece i wrote about this: http://dret.typepad.com/dretblog/2016/04/robust-extensibility.html

@dret commented on GitHub (Apr 28, 2017): i think part of the problem here is that APIs do not exist in a vacuum. they exist to be consumed. and they depend on *how* they are consumed. hence it is critically important that consumption is well-defined, meaning that consumers must follow consumption rules. i call this "processing model" because it refers to how API consumers MUST process things. to me, any API *not* having a processing model is heading for trouble. here is a brief piece i wrote about this: http://dret.typepad.com/dretblog/2016/04/robust-extensibility.html

GiteaMirror commented

2026-06-13 12:41:57 -05:00

@jwdonahue commented on GitHub (Jul 14, 2018):

@colomet, I am not sure what the issue is here. I suspect the crux of it may stem from the diamond point dependency problem, AKA: dependency hell. It's a very common issue with frameworks (plug-in architectures) that do not support side-by-side deployments of transitive dependencies, but the SemVer spec, while a small part of the solution, isn't intended to solve it. The intro/summary texts you referenced in your original post seem perfectly consistent to me.

Please either rephrase your issue or close it at your earliest possible convenience. Thank you.

@jwdonahue commented on GitHub (Jul 14, 2018): @colomet, I am not sure what the issue is here. I suspect the crux of it may stem from the [diamond point dependency problem](https://www.google.com/search?source=hp&ei=UHxKW9XML8LG0PEPl96qaA&q=diamond+point+dependency+problem&oq=diamond+point+dependency+problem&gs_l=psy-ab.3..33i21k1.793.13578.0.14590.44.44.0.0.0.0.136.3681.40j4.44.0..2..0...1.1.64.psy-ab..0.43.3609...0j0i131k1j0i22i30k1j33i160k1j33i22i29i30k1.0.6rowtqwsBUY), AKA: dependency hell. It's a very common issue with frameworks (plug-in architectures) that do not support side-by-side deployments of transitive dependencies, but the SemVer spec, while a small part of the solution, isn't intended to solve it. The intro/summary texts you referenced in your original post seem perfectly consistent to me. Please either rephrase your issue or close it at your earliest possible convenience. Thank you.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#4517