[GH-ISSUE #501] Implications of "Docs as Code" #6360

New Issue

GiteaMirror · 2026-06-17T05:06:45-05:00

GiteaMirror commented

2026-06-17 05:06:45 -05:00

Originally created by @ccallawa on GitHub (Feb 22, 2019).
Original GitHub issue: https://github.com/semver/semver/issues/501

Given that more developers are moving to the model of very tightly coupling documentation with code releases, you could add something about the implications, e.g.:

Bugfix releases (patch version, x.y.v -> x.y.w) should contain no new documentation that is not a clarification of existing documentation, on the principle that fixing bugs doesn't add new functionality, but rather makes the code work as the documentation already described it. Clarifications should only address why the documentation wasn't specific enough in the first place due to mistaken assumptions.
Every feature change in a minor version update (x.v.z -> x.w.z) must be accompanied by the documentation for each change marked as a new feature in the changelog

Originally created by @ccallawa on GitHub (Feb 22, 2019). Original GitHub issue: https://github.com/semver/semver/issues/501 Given that more developers are moving to the model of very tightly coupling documentation with code releases, you could add something about the implications, e.g.: - Bugfix releases (patch version, x.y.v -> x.y.w) should contain no new documentation that is not a clarification of existing documentation, on the principle that fixing bugs doesn't add new functionality, but rather makes the code work as the documentation already described it. Clarifications should only address why the documentation wasn't specific enough in the first place due to mistaken assumptions. - Every feature change in a minor version update (x.v.z -> x.w.z) must be accompanied by the documentation for each change marked as a new feature in the changelog

GiteaMirror added the waiting for PR label 2026-06-17 05:06:45 -05:00

GiteaMirror commented

2026-06-17 05:06:47 -05:00

@FichteFoll commented on GitHub (Feb 22, 2019):

Given that the "Public API" is usually defined by documentation, this seems to be covered by semver already.
Imo the Public API part of the spec should be clarified instead.

@FichteFoll commented on GitHub (Feb 22, 2019): Given that the "Public API" is usually *defined* by documentation, this seems to be covered by semver already. Imo the Public API part of the spec should be clarified instead.

GiteaMirror commented

2026-06-17 05:06:47 -05:00

@jwdonahue commented on GitHub (Jan 17, 2020):

@ccallawa, unless you intend to issue a PR or have further questions, please close this issue at your earliest possible convenience.

@jwdonahue commented on GitHub (Jan 17, 2020): @ccallawa, unless you intend to issue a PR or have further questions, please close this issue at your earliest possible convenience.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6360