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.
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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.
@jwdonahue commented on GitHub (Nov 30, 2017):
@emperorz
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:
@Tieske commented on GitHub (Dec 3, 2017):
See #415