[GH-ISSUE #361] (not really an issue) Request for feedback: San Diego Versioning #2983

New Issue

GiteaMirror · 2026-04-25T17:08:31-05:00

GiteaMirror commented

2026-04-25 17:08:31 -05:00

Originally created by @bshanks on GitHub (Mar 24, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/361

Hi, this is not a suggestion for a change to SemVer, but rather a request for feedback on an alternate versioning standard; sorry to pollute this issue tracker, but I can't think of many other ways to find people who have thought about the details of versioning standards.

https://github.com/bshanks/sdver

SdVer is inspired by and derived from SemVer. The major differences are:

SdVer bumps the MINOR version for backwards incompatibilities and reserves MAJOR version bumps for subjectively "big" changes. For example, version 1.3.0 might be backwards-incompatible with 1.2.3 -- the decision of whether to bump the major version to 2 is purely subjective. New functionality can be included in patch version bumps.
SdVer defines length limits, making it easier to write tooling that accepts all valid San Diego Versioning identifiers

SdVer can be summarized as "San Diego version identifiers look like MAJOR.MINOR.PATCH (possibly followed by optional parts "-PRE_RELEASE+BUILD_METADATA"). At least the MINOR version MUST be incremented when a backwards-incompatible change is made, except when MAJOR is 0."

Please leave your feedback either in issues at https://github.com/bshanks/sdver , or in comments here. Please also leave recommendations for whom else I should contact to ask for feedback. Thanks.

Originally created by @bshanks on GitHub (Mar 24, 2017). Original GitHub issue: https://github.com/semver/semver/issues/361 Hi, this is not a suggestion for a change to SemVer, but rather a request for feedback on an alternate versioning standard; sorry to pollute this issue tracker, but I can't think of many other ways to find people who have thought about the details of versioning standards. https://github.com/bshanks/sdver SdVer is inspired by and derived from SemVer. The major differences are: * SdVer bumps the MINOR version for backwards incompatibilities and reserves MAJOR version bumps for subjectively "big" changes. For example, version 1.3.0 might be backwards-incompatible with 1.2.3 -- the decision of whether to bump the major version to 2 is purely subjective. New functionality can be included in patch version bumps. * SdVer defines length limits, making it easier to write tooling that accepts all valid San Diego Versioning identifiers SdVer can be summarized as "San Diego version identifiers look like MAJOR.MINOR.PATCH (possibly followed by optional parts "-PRE_RELEASE+BUILD_METADATA"). At least the MINOR version MUST be incremented when a backwards-incompatible change is made, except when MAJOR is 0." Please leave your feedback either in issues at https://github.com/bshanks/sdver , or in comments here. Please also leave recommendations for whom else I should contact to ask for feedback. Thanks.

GiteaMirror closed this issue

2026-04-25 17:08:32 -05:00

GiteaMirror commented

2026-04-25 17:08:33 -05:00

@hofmand commented on GitHub (May 17, 2017):

The problem with SdVer is that incrementing the major version number implies that the public API has changed in an incompatible way, but this may not be true. Marketing may like SdVer but your customers might not be so thrilled with it.

@hofmand commented on GitHub (May 17, 2017): The problem with SdVer is that incrementing the major version number implies that the public API has changed in an incompatible way, but this may not be true. Marketing may like SdVer but your customers might not be so thrilled with it.

GiteaMirror commented

2026-04-25 17:08:34 -05:00

@bshanks commented on GitHub (May 29, 2017):

Thanks Mr. Hofmann, that's a good point. I can't think of a good way to fix it (without giving up either the idea that there is some sort of 'major version' which is not bumped for every backwards-incompatible change, or giving up the idea that backwards-incompatible changes are indicated by version bumps), can you?

I am not sure that customers would dislike this tradeoff. As a 'customer' of projects myself, on previous occasions i have found myself wishing that there were a quick way for me to see whether some Semver-using project has gone through one or more 'major' changes since the last time i checked in on it. For me as a customer, the value of Semver is being able to be certain that a given minor change IS backwards-compatible; being able to be certain that a given change is NOT backwards-compatible is not as important (if a change is both 'major' (in the marketing sense) and backwards-compatible this would be merely a pleasant surprise).

@bshanks commented on GitHub (May 29, 2017): Thanks Mr. Hofmann, that's a good point. I can't think of a good way to fix it (without giving up either the idea that there is some sort of 'major version' which is not bumped for every backwards-incompatible change, or giving up the idea that backwards-incompatible changes are indicated by version bumps), can you? I am not sure that customers would dislike this tradeoff. As a 'customer' of projects myself, on previous occasions i have found myself wishing that there were a quick way for me to see whether some Semver-using project has gone through one or more 'major' changes since the last time i checked in on it. For me as a customer, the value of Semver is being able to be certain that a given minor change IS backwards-compatible; being able to be certain that a given change is NOT backwards-compatible is not as important (if a change is both 'major' (in the marketing sense) and backwards-compatible this would be merely a pleasant surprise).

GiteaMirror commented

2026-04-25 17:08:35 -05:00

@jwdonahue commented on GitHub (Nov 28, 2017):

Marketing, or engineers who occasionally wear that hat, are free to paste any labeling on their packages that they deem advantageous. Look at any cereal box, appliance, other products on store shelves, and you will see lots of big colorful labeling and trademarks. Pick it up and look at the bottom or back panel and there will be some nondescript numbers and letters, often embossed into the package, that clearly identifies what's really in the box. But the chances are good that you'll have to contact the individual companies to learn how to decipher most of it. SemVer is more about indicating what's really in the box, using an open standard, that allows you to make reasonably informed choices.

Please close this issue and add your link to the Related Standards section of the SemVer Wiki if you still feel it deserves consideration.

@jwdonahue commented on GitHub (Nov 28, 2017): Marketing, or engineers who occasionally wear that hat, are free to paste any labeling on their packages that they deem advantageous. Look at any cereal box, appliance, other products on store shelves, and you will see lots of big colorful labeling and trademarks. Pick it up and look at the bottom or back panel and there will be some nondescript numbers and letters, often embossed into the package, that clearly identifies what's really in the box. But the chances are good that you'll have to contact the individual companies to learn how to decipher most of it. SemVer is more about indicating what's really in the box, using an open standard, that allows you to make reasonably informed choices. Please close this issue and add your link to the Related Standards section of the [SemVer Wiki](https://github.com/semver/semver/wiki/Semantic-Versioning-(AKA:-SemVer)) if you still feel it deserves consideration.

GiteaMirror commented

2026-04-25 17:08:35 -05:00

@bshanks commented on GitHub (Nov 29, 2017):

Thanks Mr. Donahue, I agree that this issue has been open long enough, I'll close it now. For any others reading this, I'm still working on SdVer and still would like your feedback, so if it suits you to do so, please take a look and leave feedback at https://gitlab.com/bshanks/sdver .

Mr. Donahue, regarding the point about marketing, SemVer tells the reader whether a given update includes ANY new functionality, which is (mostly) objective. SdVer replaces this with telling the reader whether a given update includes SIGNIFICANT new functionality, which is subjective. I feel that the latter is more useful than the former for making reasonably informed choices, even though it is subjective.

This sort of information is present in the version identifier in some schemes, but not in SemVer. Unlike a cereal box, at the moment when a user wants to know whether or not a particular software update is or is not "big", there is often not any other "labeling" provided by the developers at hand. For example, when you are browsing a repository, or when you read a blog post tangentially mentions a version of a software library that you use, you might notice that a new version is available and wonder if it's worth your time to learn more about it. It takes only a moment to turn a cereal box around and read the labeling, but it takes a few minutes to locate the project for a piece of software and then to locate the place where that project makes pronouncements on whether or not some release number is exciting, and then to locate the pronouncement (or lack thereof) corresponding to the newest release. This is why I think it's nicer to have this information included in the version identifier.

@bshanks commented on GitHub (Nov 29, 2017): Thanks Mr. Donahue, I agree that this issue has been open long enough, I'll close it now. For any others reading this, I'm still working on SdVer and still would like your feedback, so if it suits you to do so, please take a look and leave feedback at https://gitlab.com/bshanks/sdver . Mr. Donahue, regarding the point about marketing, SemVer tells the reader whether a given update includes ANY new functionality, which is (mostly) objective. SdVer replaces this with telling the reader whether a given update includes SIGNIFICANT new functionality, which is subjective. I feel that the latter is more useful than the former for making reasonably informed choices, even though it is subjective. This sort of information is present in the version identifier in some schemes, but not in SemVer. Unlike a cereal box, at the moment when a user wants to know whether or not a particular software update is or is not "big", there is often not any other "labeling" provided by the developers at hand. For example, when you are browsing a repository, or when you read a blog post tangentially mentions a version of a software library that you use, you might notice that a new version is available and wonder if it's worth your time to learn more about it. It takes only a moment to turn a cereal box around and read the labeling, but it takes a few minutes to locate the project for a piece of software and then to locate the place where that project makes pronouncements on whether or not some release number is exciting, and then to locate the pronouncement (or lack thereof) corresponding to the newest release. This is why I think it's nicer to have this information included in the version identifier.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#2983