Skip to content
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

I think I see an inconsistency of semver. #366

Closed
colomet opened this issue Apr 26, 2017 · 6 comments
Closed

I think I see an inconsistency of semver. #366

colomet opened this issue Apr 26, 2017 · 6 comments

Comments

@colomet
Copy link

colomet commented Apr 26, 2017

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.

@colomet
Copy link
Author

colomet commented 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

@krzysiekpiasecki
Copy link
Contributor

krzysiekpiasecki commented 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.

@colomet
Copy link
Author

colomet commented Apr 26, 2017

what is a public API?

@krzysiekpiasecki
Copy link
Contributor

krzysiekpiasecki commented 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?

@dret
Copy link

dret commented 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

@jwdonahue
Copy link
Contributor

jwdonahue commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants