mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #541] Change wording "public api" to reduce confusion #7372
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @binyamin on GitHub (Dec 4, 2019).
Original GitHub issue: https://github.com/semver/semver/issues/541
Request
Or
Reason
Most developers think of the term API as referring to code, ie, programmatically accessible endpoints on a web server.
It seems from both the wording of the SemVer specs () and the issues and questions (see #453, #468, stack overflow) which have been raised regarding the term, that the generally understood definition is not the indented meaning.
While the term may be used correctly in the specs, it does not convey the clarity for which documentation and specifications aim.
@runeimp commented on GitHub (Dec 5, 2019):
@b3u API is a general term in programming. It's not specific to the web in any way. And is meant to be very generic. Those links have a huge amount of discussion on the topic for a reason. The concept is (in general) simple but the range of implementations is massive and most of them have many different factors that need consideration regarding their own concept of a Public API. This makes documentation that works for every single case next to impossible. But if you have some clever way to summarize the incredible diversity of factors that need to be considered to construe and embody the scope of what a Public API is in every given scenario then please share those ideas. But, unfortunately, I can pretty much guarantee you that simply changing the wording "Public API" to something else is going to be just as confusing (if not more so) than what already exists. Also restating that there is confusion about something, and citing massive discussion talking about the confusion on the platform that is home to most of those discussions, and not providing any concrete suggestions after years of work has already gone into the docs is not helpful. The authors of the spec are aware of the limitations of the doc and have not made a call for input or help to improve the docs beyond what was cited. Please either add your own concrete ideas or close this issue.
I, for one, am grateful the authors created the SemVer spec and have put as much time into maintaining and improving the spec as they have. They are generous and rather accepting of ideas and discussions that have merit. If you have real ideas please share them. Everyone would love to see more clarification in the docs. If you don't, then why are you posting this?
@binyamin commented on GitHub (Dec 5, 2019):
@runeimp I apologize for any offense I may have given.
I can't give an alternative, because I myself have no idea what the term "Public API" means in this circumstance. If you can point me to an explanation, I would love to draft a proposal for the docs.
@ljharb commented on GitHub (Dec 5, 2019):
API stands for "application programming interface" - it's "how you interact with the thing from code". It likely includes (but may not include all of):
This is not an exhaustive list.
@sungam3r commented on GitHub (Dec 5, 2019):
Even message format, encoding, byte order, etc. may be considered as a part of public api.
@binyamin commented on GitHub (Dec 5, 2019):
Thank you
@runeimp commented on GitHub (Dec 11, 2019):
@b3u I'm sorry but your post makes me angry. I'm almost certainly over reacting and I don't know why. I quite well remember my own confusion when I originally started learning programming and concepts such as API, OOP, MVC, and the rest of the alphabet soup programmers deal with regularly. And not knowing why your post strikes such a chord with me frustrates me even more.
Thank you for your apology. It is appreciated but unnecessary as you were obviously not malicious in your post. You are a better person than I for extending it. I wish to extend my own apology as my response was heavy handed and that was unwarranted. I'm sorry.