[GH-ISSUE #339] A clarifying fix #5363

Open
opened 2026-06-15 11:42:03 -05:00 by GiteaMirror · 2 comments
Owner

Originally created by @emperorz on GitHub (Oct 23, 2016).
Original GitHub issue: https://github.com/semver/semver/issues/339

To clarify the distinction between the external behaviour (the public API), and the internal implementation I would suggest:

In the summary about PATCH, replace "backwards compatible bug fixes" with "API identical implementation changes". Backwards compatible is redundant with the previous line, and we may be refactoring or otherwise reimplementing.

Originally created by @emperorz on GitHub (Oct 23, 2016). Original GitHub issue: https://github.com/semver/semver/issues/339 To clarify the distinction between the external behaviour (the public API), and the internal implementation I would suggest: In the summary about PATCH, replace "backwards compatible bug fixes" with "API identical implementation changes". Backwards compatible is redundant with the previous line, and we may be refactoring or otherwise reimplementing.
GiteaMirror added the spelling/grammarwaiting for PR labels 2026-06-15 11:42:03 -05:00
Author
Owner

@jwdonahue commented on GitHub (Nov 30, 2017):

@emperorz

"API identical implementation changes"

I have to think too hard to grok that phrase and there is some debate regarding the use of "API" in the spec, but I see your point, 'refactor' not in 'bug-fixes'. How about "backwards-compatible changes (bug fixes, refactors, etc.)"?

I think a refactor generally carries more risk than a bug fix. But the spec doesn't limit the number of changes per patch. It seems to be focused on the interface.

Please do one or more of the following:

  • Clone semver/semver.org, make the proposed changes and issue a pull-request.
  • Close this issue at your earliest convenience.
<!-- gh-comment-id:348114219 --> @jwdonahue commented on GitHub (Nov 30, 2017): @emperorz > "API identical implementation changes" I have to think too hard to grok that phrase and there is some debate regarding the use of "API" in the spec, but I see your point, 'refactor' not in 'bug-fixes'. How about "backwards-compatible changes (bug fixes, refactors, etc.)"? I think a refactor generally carries more risk than a bug fix. But the spec doesn't limit the number of changes per patch. It seems to be focused on the interface. Please do one or more of the following: - Clone semver/semver.org, make the proposed changes and issue a pull-request. - Close this issue at your earliest convenience.
Author
Owner

@Tieske commented on GitHub (Dec 3, 2017):

See #415

<!-- gh-comment-id:348811231 --> @Tieske commented on GitHub (Dec 3, 2017): See #415
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#5363