mirror of
https://github.com/semver/semver.git
synced 2026-07-11 03:53:53 -05:00
[GH-ISSUE #321] Explicit Versioning - Something that might replace the Semantic Versioning #6222
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#6222
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 @sapioit on GitHub (Jul 5, 2016).
Original GitHub issue: https://github.com/semver/semver/issues/321
It's so simple it can be explained in only four words and still expect most of the people to just get it: Release.Breaking.Feature.Fix
No more ambiguity cause by the "Major" and "Minor" words, now you know exactly what each number stands for without even needing a description. But if you need one, I'll give one, because science! Computer science!
Release.Breaking.Feature.Fixor why the Semantic Versioning should be replaced with Explicit Versioning as soon as possible@FichteFoll commented on GitHub (Jul 5, 2016):
Is this advertisement for your semver fork or an actual suggestion to change semver itself?
Besides, you should proof-read your article. If you did already, do it again.
@sapioit commented on GitHub (Jul 6, 2016):
An actual suggestion to change semver itself.
I just proof-reded my article again... and I don't get where you are getting. Please point out what am I failing to notice.
@crazedsanity commented on GitHub (Jul 6, 2016):
Something like this has been suggested before. I think four version numbers is too much, personally; having "extension" of SemVer to express this might be better.
As to the "proof-reded" article... both sentences in the second paragraph. It should be proofread again, with a spell checker. It looks a little like more like advertisement for another (proposed?) system and less like a change.
@sapioit commented on GitHub (Jul 6, 2016):
Oh my god, so many errors... Thanks for suggesting me to use a spell checker... I've been staring at the article I wrote for so long that I just bypassed all those errors. There should be no errors left by now... hopefully...
@flimzy commented on GitHub (Apr 15, 2017):
This seems like a solution to a problem nobody has.
@sapioit commented on GitHub (Apr 15, 2017):
There are many things in this world that are not what they seem...
@colomet commented on GitHub (Apr 26, 2017):
If you work with an adroid app, maybe 3 digits are fine for you. I work with wordpress, where the wordpress itself use the last digit just for bugs. Is normall to use on digit just for bux because if you integrate with many other developments, a new feature can be a breaking change not a bug. that´s why maybe better a 4 digit approach.
@Exadra37 commented on GitHub (Apr 26, 2017):
@flimzy is problem that lots o people have.
Why?
Because lots of the big players and Developers don't use SemVer or don't use it properly.
I completely agree with the 4 digits and I actively use it in my repositories, by following my own spec.
But instead of having to follow my own spec I would prefer to see SemVer being fixed.
@flimzy commented on GitHub (Apr 26, 2017):
So the solution to not using SemVer, or abusing it, is to introduce another standard? That doesn't make sense at all.
@Exadra37 commented on GitHub (Apr 26, 2017):
Not introducing another standard, just fix this Standard that is broken and flawed.
Doesn't make sense to have 4 digits to explicit handing Software Releases?
So you prefer implicit over explicit declarations?
What does not make sense is for SemVer affectionate's to not recognise the problem ;)
@FichteFoll commented on GitHub (Apr 26, 2017):
I prefer standards with little to no redundancy. And standards that suit the task they are designed for.
As @jeme outlined in the other issue (https://github.com/mojombo/semver/issues/340#issuecomment-296995758), SemVer is for your consumers, your users and clients, and not for you, the author. And as a consumer of a library, I realistically only care about the three attributes that the individual parts of a semantic version provide: backwards-incompatible breaking changes (major), feature additions (minor) and "anything else", e.g. bugfixes, (patch). The fourth number is always something that the developer wants to provide as a matter of justification or because they like pretty (smaller) numbers.
Again, you are free do to whatever you want with versioning your software, as long as you do not claim to support or follow the semantic versioning standard outlined at semver.org when you in fact aren't. (And your naming is indeed confusing because of that.)
@sapioit commented on GitHub (Apr 26, 2017):
My point is: If one can interpret a text wrong, someone, somewhere, one WILL interpret it wrong. And the more such implicit declarations a text has, the more it WILL stray from it's intended usage.
That is why the law system tries to be as explicit as possible (but fails for the same reasons SemVer does: implicit declarations).
Let me give you a grim example: Batman doesn't kill people, but getting them in situations in which they will die in a short while is not much different from that. That's one way to look at the difference between implicit and explicit.
@flimzy commented on GitHub (Apr 26, 2017):
Of course this is true. But switching from "SemVer" to "ExpVer" does not, nor cannot solve this.
All it does is add an additional number to be possibly confused about.
@Exadra37 commented on GitHub (Apr 26, 2017):
@FichteFoll
You make the point... SemVer is full of redundancy and space to misinterpretation, because is not Explicit in is intents, rather things are implicit, therefore open to interpretation.
Don't put words in my mouth. I never said that I support SemVer as it is in this repo or in the website... I say precisely the opposite.
But yes I say I support Semantic Versioning properly, but I point to my own specification, not to SemVer specification.
And I am very clear in saying why I don't use SemVer here.
Conlusion
As i said before I prefer to see 4 digits come to SemVer, than Developers have the need to switch to other Specification to have Software Versioning done in a explicit way.
As far as I am concerned I will not waste more time discussing this matter, once people are acting like if a fan club matter was being discussed.
Not matter what your club does, is your club, therefore your club is always correct not matter what evidences are presented against it.
@FichteFoll commented on GitHub (Apr 26, 2017):
Sorry, I didn't mean to address you directly with this section. Replace "you" with "one".
I don't have anything else to add to this discussion.
@Exadra37 commented on GitHub (Apr 26, 2017):
@FichteFoll no problem :)
@sapioit commented on GitHub (Apr 26, 2017):
No, but highly decreases the level of redudancy required for multiple parties to understand the same thing, by making the definitions of each field as explicit as possible without losing generality (compatibility).
In other words, all I try to do is decrease the cyclometric complexity of the terms of use of SimVer, thereby resulting in offering a more clear and easier to understand and follow set of guidlines. And I think the compact name shall be
ExpliVer... it has a different sound to it.SimVer works so well because it was one of the best guidlines at the moment of it's conception, but that does not mean that it's still one of the best options out there, but only that it's one of the most used ones.
@colomet commented on GitHub (Apr 26, 2017):
@Exadra37 @sapioit what do you think about that?
https://colomet.github.io/php-cms-versioning/
@sapioit commented on GitHub (Apr 26, 2017):
That's more like it, but the name is too big and difficult to both remember and separate from a cms which deals with php versioning, and is too particular (as in: not general enough).
Why not just
CMSver, without tieing it to php-only? Or better yet,DevVer(which rhymes with differ and looks like the contracted form of developer)** to not tie it with cms-only?**Also, please add social/share buttons on that page, so people can share it around easier.
@jwdonahue commented on GitHub (Feb 26, 2018):
@sapioit, please close this issue at your earliest possible convenience.
@sapioit commented on GitHub (Aug 8, 2018):
Note: The official name for my suggestion is now Explicit Versioning.
@jwdonahue commented on GitHub (Aug 8, 2018):
@sapioit, thank you! I think there should be lots of well defined versioning schemes, but I fear the chaos that will ensue if we can't tell one from the other. Please take a look at VersionMeta, I'll be happy to work with your on an appropriate tag and VersionSchema. I've been close to publishing VersionSchema for a few months now, but keep getting distracted.