[PR #682] [CLOSED] RFC proposal for semver 3.0.0 - LIBRARY version #2573

New Issue

GiteaMirror · 2026-04-20T10:31:20-05:00

GiteaMirror commented

2026-04-20 10:31:20 -05:00

📋 Pull Request Information

Original PR: https://github.com/semver/semver/pull/682
Author: @coldnebo
Created: 3/26/2021
Status: ❌ Closed

Base: master ← Head: master

📝 Commits (1)

b0ff028 RFC proposal for semver 3.0.0

📊 Changes

1 file changed (+35 additions, -23 deletions)

View changed files

📝 semver.md (+35 -23)

📄 Description

While looking at Rails versioning, I notice that some PATCH level changes have breaking changes now. For example:

Update Changelog entry for 5.2.4.1 to warn of breaking changes

SemVer 2.0 says:

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API

If Rails followed this advice, then the logical semver increment from 5.2.4 would have to be 6.x, not 5.2.4.1. But Rails 6.x already means something bigger than an incompatible API change -- it means a group of incompatible architectural changes with the previous version.

Indeed, many gems in the ecosystem face this dilemma.

Proposal: LIBRARY version

Given a version number LIBRARY.MAJOR.MINOR.PATCH, increment the:

LIBRARY version when you make incompatible architectural changes.
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.

So, for the above example, the bump could have been: 5.3.0.0

_{🔄 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/682 **Author:** [@coldnebo](https://github.com/coldnebo) **Created:** 3/26/2021 **Status:** ❌ Closed **Base:** `master` ← **Head:** `master` --- ### 📝 Commits (1) - [`b0ff028`](https://github.com/semver/semver/commit/b0ff028dd326389c144754f98c14431648522cec) RFC proposal for semver 3.0.0 ### 📊 Changes **1 file changed** (+35 additions, -23 deletions) <details> <summary>View changed files</summary> 📝 `semver.md` (+35 -23) </details> ### 📄 Description While looking at Rails versioning, I notice that some PATCH level changes have breaking changes now. For example: * [Update Changelog entry for 5.2.4.1 to warn of breaking changes](https://github.com/rails/rails/commit/c1ca9c7b365cdac9ccd8eb1716173ea3aef89892) SemVer 2.0 says: > 8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API If Rails followed this advice, then the logical semver increment from 5.2.4 would have to be 6.x, not 5.2.4.1. But Rails 6.x already means something bigger than an incompatible API change -- it means a group of incompatible architectural changes with the previous version. Indeed, many gems in the ecosystem face this dilemma. ## Proposal: LIBRARY version Given a version number LIBRARY.MAJOR.MINOR.PATCH, increment the: LIBRARY version when you make incompatible architectural changes. MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards compatible manner, and PATCH version when you make backwards compatible bug fixes. So, for the above example, the bump could have been: 5.3.0.0 --- <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-04-20 10:31:20 -05:00

GiteaMirror closed this issue

2026-04-20 10:31:22 -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#2573