mirror of
https://github.com/semver/semver.git
synced 2026-07-11 06:53:03 -05:00
[GH-ISSUE #554] clarification on "API" meaning in case of executables versioning #3118
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#3118
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 @mastupristi on GitHub (Mar 28, 2020).
Original GitHub issue: https://github.com/semver/semver/issues/554
Throughout the text you refer to the term API (Application programming interface):
The term "public APIs" makes me think of a library that should provide functionality and for this reason it is necessary to define public APIs to which the concepts of compatibility/incompatibility that drive the version change apply. Isn't that right?
But I write bare-metal executables for embedded devices. They do not expose any API. How should I implement the change of MAJOR, MINOR and PATCH?
best regards
Mac
@ljharb commented on GitHub (Mar 28, 2020):
There’s no i/o in your programs?
@mastupristi commented on GitHub (Mar 28, 2020):
Not at all. Usually our devices have at most some LEDs, and no graphic/textual interface. They rarely have an RS485 or ethernet communication interface.
We produce pro-audio amplifiers for rack or amplified loudspeakers, so the man-machine interface is not so important.
@ljharb commented on GitHub (Mar 28, 2020):
Sure, but they still have intended functionality - something goes in (even if that's "current" or "sound" or "a dial that goes to eleven") and something comes out ("sound" or "current" or "lights").
@mastupristi commented on GitHub (Mar 28, 2020):
That's true, but the hardware does that.
Our firmware makes sure that it doesn't burn out the amplifier or the speakers connected to it, while trying to get the hardware to the highest possible limits.
@ljharb commented on GitHub (Mar 28, 2020):
Sounds like that's your API then :-) the rating/tolerance, or whatever it's called.
@Nyameliaaaa commented on GitHub (Mar 31, 2020):
What If The Software Is Something That Uses An API.
@ljharb commented on GitHub (Mar 31, 2020):
What it consumes is a dependency like anything else, no? Sometimes a deps’ requirements leak and become your own, but most of the time they’re a silent implementation detail.
@mastupristi commented on GitHub (Mar 31, 2020):
You may be right, but the boundaries aren't that sharp. Even if one wants to express them, and specify them.
Too much would be left to interpretation. It may happen that a change on one occasion may lead to a change in the MINOR number, and on another occasion it causes the MAJOR number to change.
In this context, only PATCH number changes can be clearly defined.
@ljharb commented on GitHub (Mar 31, 2020):
It’s not clearly defined generically, but for any project, it can and should be explicitly defined. Minor is for additions, major is for breaking changes, patch is for everything else.
It doesn’t sound like your project would be likely to have additions, however.
@jwdonahue commented on GitHub (Apr 2, 2020):
The whole point of the SemVer spec, is to define a means for software publishers to communicate risk to their customers.
In your case, most of your products interfaces are purely electrical. There's no network protocols or API's to version for your external customers. Your production line(s) however, have different needs. Your firmware file names probably encode information about the target hardware they are intended for, and possibly other information. It's not uncommon to embed version information there as well. You may find that applying the SemVer concepts to your version strings makes sense, but it really depends on your internal processes. When you are essentially your own customer, you can evolve any system that works for you. If your mgf lines are not owned by you, you will need to establish work-flows with them, and they may have some pretty good ideas how to manage it.