[GH-ISSUE #555] clarification on "API" meaning in case of executables versioning #7378

New Issue

GiteaMirror · 2026-06-20T17:24:36-05:00

GiteaMirror commented

2026-06-20 17:24:36 -05:00

Originally created by @mastupristi on GitHub (Mar 28, 2020).
Original GitHub issue: https://github.com/semver/semver/issues/555

Throughout the text you refer to the term API (Application programming interface):

For this system to work, you first need to declare a public API. This may consist of documentation or be enforced by the code itself. Regardless, it is important that this API be clear and precise. Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). 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.

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
Max

Originally created by @mastupristi on GitHub (Mar 28, 2020). Original GitHub issue: https://github.com/semver/semver/issues/555 Throughout the text you refer to the term **API** (Application programming interface): > For this system to work, you first need to declare a **public API**. This may consist of documentation or be enforced by the code itself. Regardless, it is important that this **API** be clear and precise. Once you identify your **public API**, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). 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. 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 Max

GiteaMirror closed this issue

2026-06-20 17:24:36 -05:00

GiteaMirror commented

2026-06-20 17:24:37 -05:00

@ljharb commented on GitHub (Mar 28, 2020):

Duplicate of #554.

@ljharb commented on GitHub (Mar 28, 2020): Duplicate of #554.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#7378