When reading the description for major version zero I came across the line "Anything may change
at any time." I would like to create a more clear explanation of how versioning should take place before the first stable version of the public API so that developers can have meaning behind their pre-stable versioning.
This is especially an issue in node.js development as by default saved modules will pick up new patch versions but not new minor versions. If developers don't properly version their modules in a pre-stable state they can potentially break when users pick up new patch versions.
To define this pre-stable state I have proposed moving the definition for major and minor changes to the right, meaning that API-breaking changes result in a minor version being incremented and both backwards-compatible functional additions as well as bug fixes result in a patch version being incremented.
🔄 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/127
**Author:** [@ChrisWren](https://github.com/ChrisWren)
**Created:** 7/1/2013
**Status:** 🔄 Open
**Base:** `master` ← **Head:** `master`
---
### 📝 Commits (2)
- [`3089fce`](https://github.com/semver/semver/commit/3089fce7ba33c2ffad8beecbfa98aa44aaf68101) Added description for pre-stable public API versioning
- [`c26eb8d`](https://github.com/semver/semver/commit/c26eb8d050822ffbe43a2b7a67b3203da6832c5b) Removed FAQ about 0.y.z revisioning
### 📊 Changes
**1 file changed** (+9 additions, -7 deletions)
<details>
<summary>View changed files</summary>
📝 `semver.md` (+9 -7)
</details>
### 📄 Description
When reading the description for major version zero I came across the line "Anything may change
at any time." I would like to create a more clear explanation of how versioning should take place before the first stable version of the public API so that developers can have meaning behind their pre-stable versioning.
This is especially an issue in node.js development as by default saved modules will pick up new patch versions but not new minor versions. If developers don't properly version their modules in a pre-stable state they can potentially break when users pick up new patch versions.
To define this pre-stable state I have proposed moving the definition for major and minor changes to the right, meaning that API-breaking changes result in a minor version being incremented and both backwards-compatible functional additions as well as bug fixes result in a patch version being incremented.
---
<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
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.
📋 Pull Request Information
Original PR: https://github.com/semver/semver/pull/127
Author: @ChrisWren
Created: 7/1/2013
Status: 🔄 Open
Base:
master← Head:master📝 Commits (2)
3089fceAdded description for pre-stable public API versioningc26eb8dRemoved FAQ about 0.y.z revisioning📊 Changes
1 file changed (+9 additions, -7 deletions)
View changed files
📝
semver.md(+9 -7)📄 Description
When reading the description for major version zero I came across the line "Anything may change
at any time." I would like to create a more clear explanation of how versioning should take place before the first stable version of the public API so that developers can have meaning behind their pre-stable versioning.
This is especially an issue in node.js development as by default saved modules will pick up new patch versions but not new minor versions. If developers don't properly version their modules in a pre-stable state they can potentially break when users pick up new patch versions.
To define this pre-stable state I have proposed moving the definition for major and minor changes to the right, meaning that API-breaking changes result in a minor version being incremented and both backwards-compatible functional additions as well as bug fixes result in a patch version being incremented.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.