mirror of
https://github.com/semver/semver.git
synced 2026-07-11 06:53:03 -05:00
[GH-ISSUE #449] Dealing with Marketing concerns #2061
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#2061
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @littlefyr on GitHub (Jul 13, 2018).
Original GitHub issue: https://github.com/semver/semver/issues/449
Working with SemVer outside of OSS means that you have to deal with marketing type concerns. These are legitimate concerns and simply having the first digit grow with every breaking change, or only change with every breaking change is counter intuitive, particularly if you are talking about user facing apps. A major UI change may only be a minor, non-breaking change, but from a business point of view, its a big deal so it "deserves" an increment of the major version.
And sometimes we just don't have a choice.
It would be helpful, when dealing with these situations, if SemVer allowed the following without breaking any of the other semantics:
Marketing.Major.Minor.Patch-PreRelease.Tags+Meta.Data. In this case, the rules all apply as before, except that there are no semantics about when the Marketing number should change. Naturally, the Marketing value should be Optional@Hexstream commented on GitHub (Jul 14, 2018):
Seems like a very disruptive change, if adopted.
I think you could simply have a developer-facing "API version" using SemVer and a separate user-facing "App version" using whatever custom convention you like.
Android already has something a bit like this. ("Version" VS "API level".)
@Hexstream commented on GitHub (Jul 14, 2018):
This seems to be a duplicate of issue #385.
@jwdonahue commented on GitHub (Jul 14, 2018):
@littlefyr
The primary focus of SemVer is API's. It's about communication between producer devs and consumer devs and has nothing at all to do with marketing. It's a technical spec that is hopefully simple enough that an engineer can explain it to a marketer, but it's complex enough to be a solution to the specified problem. The spec refers to the version string format and semantics. Nothing about it suggest that you can't add any kind of cruft before or after it on your packaging and propaganda and nothing in the spec requires you to even include the SemVer string in any of it. Its primary use is in automation, but it's also applicable to manual development processes, none of which have anything to do with marketing.
There have been many discussions here in the past, regarding the extension of the version triple for various reasons, including marketing purposes. None are likely to ever be taken seriously, though some may warrant documentation and implementation as competing standards in their own right, none make sense for SemVer and the majority of its stake-holders.
Unless you intend to follow-up with a PR or you have further questions, please close this issue at your earliest possible convenience. Thank you.
@littlefyr commented on GitHub (Jul 14, 2018):
Fair enough.
I probably should have guessed that this would be the outcome.