github-starred/semver
2
0
Fork 0
mirror of https://github.com/semver/semver.git synced 2026-07-11 04:52:47 -05:00
Code Issues 1.0k Packages Projects Releases 4 Wiki Activity

A clarifying fix #246

New Issue
Open
opened 2026-02-17 11:39:54 -06:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-02-17 11:39:54 -06:00
Owner
Copy Link

Originally created by @emperorz on GitHub (Oct 23, 2016).

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). 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-02-17 11:39:54 -06:00
GiteaMirror commented 2026-02-17 11:39:56 -06:00
Author
Owner
Copy Link

@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.
@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.
GiteaMirror commented 2026-02-17 11:39:56 -06:00
Author
Owner
Copy Link

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

See #415

@Tieske commented on GitHub (Dec 3, 2017): See #415
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
consensus seeking
duplicate
extend
layout
pull-request
Mirrored from GitHub Pull Request
 question
RFC
spelling/grammar
staled
update
waiting for PR
won't fix
No Label spelling/grammar waiting for PR
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#246
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?