[PR #152] [CLOSED] Making it clear how 0.X.Y versions work #6918

New Issue

GiteaMirror · 2026-06-18T22:24:14-05:00

GiteaMirror commented

2026-06-18 22:24:14 -05:00

📋 Pull Request Information

Original PR: https://github.com/semver/semver/pull/152
Author: @krainboltgreene
Created: 8/12/2013
Status: ❌ Closed

Base: master ← Head: patch-1

📝 Commits (3)

d652f98 Making it clear how 0.X.Y versions work
f1a7555 Making suggested corrections by maintainer
52fbd64 Fixing typo thanks to @dwijnand

📊 Changes

1 file changed (+3 additions, -2 deletions)

View changed files

📝 semver.md (+3 -2)

📄 Description

I've come up against a lot of libraries that stick to 0.X.Y versions and when challenged claim "oh we might change the API". SEMVER is supposed to give you the freedom to change your public API as long as you document the severity of that change in the version. This line gives developers something to hide behind to avoid the scary 1.X.Y declaration when in reality they're well past a stable release and being depended on by others.

I find this to be both annoying and detrimental to the use of Semantic Versioning. One major point of SEMVER is that APIs can safely change as long as a corresponding change happens to their Version.

As such I've removed the wording "api can change" because it's not descriptive of 0.X.Y. 0.X.Y should be simple: If you're still working on minimum viable functionality then you're still 0.X.Y. As soon as someone depends on you, then you should document your public API and bump the major version to 1.X.Y.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/semver/semver/pull/152 **Author:** [@krainboltgreene](https://github.com/krainboltgreene) **Created:** 8/12/2013 **Status:** ❌ Closed **Base:** `master` ← **Head:** `patch-1` --- ### 📝 Commits (3) - [`d652f98`](https://github.com/semver/semver/commit/d652f988dca7f69e09e29025377e51879c9975f0) Making it clear how 0.X.Y versions work - [`f1a7555`](https://github.com/semver/semver/commit/f1a75556c1da429c933f3a3ebd666c8fcfa1d043) Making suggested corrections by maintainer - [`52fbd64`](https://github.com/semver/semver/commit/52fbd6447dbef24ee66fe63a104e03fe15e422c5) Fixing typo thanks to @dwijnand ### 📊 Changes **1 file changed** (+3 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `semver.md` (+3 -2) </details> ### 📄 Description I've come up against a lot of libraries that stick to 0.X.Y versions and when challenged claim "oh we might change the API". SEMVER is supposed to give you the freedom to change your public API as long as you document the severity of that change in the version. This line gives developers something to hide behind to avoid the scary 1.X.Y declaration when in reality they're well past a stable release and being depended on by others. I find this to be both annoying and detrimental to the use of Semantic Versioning. One major point of SEMVER is that _APIs can safely change as long as a corresponding change happens to their Version_. As such I've removed the wording "api can change" because it's not descriptive of 0.X.Y. 0.X.Y should be simple: If you're still working on minimum viable functionality then you're still 0.X.Y. As soon as someone depends on you, then you should document your public API and bump the major version to 1.X.Y. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

GiteaMirror added the pull-request label 2026-06-18 22:24:14 -05:00

GiteaMirror closed this issue

2026-06-18 22:24:15 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6918