mirror of
https://github.com/semver/semver.git
synced 2026-03-22 14:10:15 -05:00
Marketing and Third-Party compatible semantic versions #287
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#287
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 @ScreamingDev on GitHub (Jul 23, 2017).
Here is a breaking change for SemVer which might come with Semver 3:
Currently versions are like "Major.Minor.Patch" for a package.
This is quite confusing when there is a third party involved (like an API or Marketing):
So another form of semver is needed like:
{arbitrary-version}.{major}.{minor}.{patch}.Or a more generic approach just saying: "The last three numbers need to follow semver, everything in front can be as anyone wants it to be."
This solves the common issue and brings more freedom among devs, sales and third-party:
@FichteFoll commented on GitHub (Jul 25, 2017):
Sounds like you should encode the target api version in the metadata segment of the connector's semver.
@silkentrance commented on GitHub (Nov 22, 2017):
semver is not about marketing. you need to straighten up your processes.
And there is no reason why
api connectorshouldn't be using a different version than its api dependency.As for Marketing wanting to release a v1 version, just tell them no. They can communicate such a version to the public, but internally it will be totally different.
Which, of course, has been the best practice since the time that Marketing tried to evolve from being just a utility to wanting to control overall development.
As for
{arbitrary-version}.{major}.{minor}.{patch}, I personally refer to these as star dates, as in Star Trek. Absolutely artificial and overly redundant.Please close. It is not worth to be talking about.
@jwdonahue commented on GitHub (Nov 28, 2017):
Marketing and package naming/decorating conventions do not fall within the purview of SemVer, though I do think it should at least link to some common best practices. The packages names do in fact carry semantic content that can be relevant to consumers trying to make informed choices.
@jwdonahue commented on GitHub (Mar 2, 2018):
Related #265, #352.
@jwdonahue commented on GitHub (Jul 12, 2018):
@ScreamingDev, unless you intend to submit a pull-request or have further questions, can you please close this issue at your earliest possible convenience? Thank you.
@silkentrance commented on GitHub (Jul 14, 2018):
@ScreamingDev you might also want to consider tags on your semver, e.g.
if that suits you, otherwise, encode the API version in the api-connector's package name, e.g.
@markusschaber commented on GitHub (Sep 5, 2018):
As Marketing tends to rework the versioning in very irrational ways[1], it's hopeless to combine it with semantics of any kind.
You could allow some Syntax to inject Marketing labels which are just ignored for SemVer. One idea could be "Label (SemVer)" - just include the Semantic Version into brackets, and ignore everything outside the brackets.
Using a Fullstop character to split semantic and non-semantic part might be very hard for (human and machine) parsers to get right, and also cause confusion with existing legacy 4-digit numbering schemes.
[1] a popular example is Windows: 1.0 - 2.x - 3.0 - 3.00a - 3.0 with Multimedia Extensions - 3.1 - 3.11 - 95 - 95a - 95b - 95b OSR 2.1- 95c - 98 - 98SE - ME - 2000 - XP - Vista - 7 - 8 - 8.1 - 10
@ScreamingDev commented on GitHub (Sep 5, 2018):
Thanks @markusschaber and @silkentrance for your words and hints.
This remains an issue for me but for our API this has come to an easy solution:
As long as the API follows semver and assures backward compatibility and no breaking changes in Version 1 we can safely use the "foreign version" as a prefix or within the package name. This is hopefully understandable by non-developers and developers.
All other things like "Hey, my Plugin is compatible with a douche app that has arbitrary versioning" remain a feature request to semver.
@jwdonahue commented on GitHub (Sep 6, 2018):
@ScreamingDev, see VersionMeta and VersionSchema. Both a work in progress, but I could really use some feedback from potential adopters.
Unless you intend to offer a pull-request or have any other related questions, can you please close this thread at your earliest possible convenience?
@silkentrance commented on GitHub (Sep 8, 2018):
@jwdonahue VersionSchema can be accessed via http instead of https
@jwdonahue commented on GitHub (Sep 8, 2018):
@silkentrance ,
Yup, I need to fix that. For now, I edited the link. Thanks.
@jwdonahue commented on GitHub (Sep 14, 2018):
@ScreamingDev, why is this issue still open?
@jwdonahue commented on GitHub (Sep 25, 2018):
@ScreamingDev, unless you have further questions or intend to issue a PR, please close this issue at your earliest possible convenience.
@jwdonahue commented on GitHub (Oct 11, 2018):
@ScreamingDev , please close this issue.
@jwdonahue commented on GitHub (Jan 22, 2020):
@anangaur , @dherman, @indirect, @isaacs, @segiddins, @steveklabnik, @Seldaek ,
Any of you see any reason to keep this thread open? If not, please tag it as you see it fit and close it at your earliest possible convenience.
@joeboon commented on GitHub (Jun 2, 2020):
The OP examples are wrong. Based on their proposal, it would go from