"Why" example seems to be coming from an erroneous premise

[eslachance]

So, take this with a grain of salt - someone linked me this github because they wanted my opinion on the idea of Explicit Versioning instead of SemVer, so I took a quick look.

One thing strikes me as awkward, but again, I'm not invested at all in this versioning system so this is just me playing devil's advocate.

The problem I'm seeing is that The Why Page specifically mentions Laravel 4.x as an example of why one would need something else than SemVer to version stuff. But this entire section contradicts the premise, for one simple reason:

Laravel didn't start using SemVer until version 6, so version 4 didn't have to follow the MAJOR.MINOR.PATCH system, so they were introducing changes that weren't backwards compatible in minor versions. This isn't because SemVer is wrong, it's because they simply weren't using SemVer at that time.

Version 6 and higher follow SemVer ( patch notes, first item ), while versions up to 5.8 followed their own "paradigm.major.minor" versioning ( 5.8 patch notes, first item ).

So what does this tell me? It tells me the "WHY" is wrong and the entire premise is flawed. To solidify the reason why anyone would want to move away from SemVer, you should find an example of where SemVer actually fails in its own protocols, and you haven't demonstrated this.

As a side-note, your "Disruptive" vs "Breaking" versions really don't add much, since a breaking backwards-incompatible change would, by definition, always be disruptive to the user.

[Exadra37]

Laravel didn't start using SemVer until version 6, so version 4 didn't have to follow the MAJOR.MINOR.PATCH system

And I don't say the opposite as I say in the page you cited:

I use Laravel Framework professionally in a daily base, so I will use it as example to show as one that does not follow the SemVer version schema, or if you prefer, it works around it when needs to release changes that are Backwards Incompatible.

Well it seems that my above sentence and by the same reasoning the entire document can have a different interpretation, as per your conclusion:

So what does this tell me? It tells me the "WHY" is wrong and the entire premise is flawed. To solidify the reason why anyone would want to move away from SemVer, you should find an example of where SemVer actually fails in its own protocols, and you haven't demonstrated this.

So I stand by what I wrote and the premises are not wrong at all, but you and everyone else is free to disagree and/or have their own interpretations of my words, because that is out of my control ;)

Our industry is famous to stick with bad decisions from the past, just because they are already there for sometime, and some fiercely defend them while others try to find better alternatives, while other don't care if it goes one way or the other ;)

---

As a side-note, your "Disruptive" vs "Breaking" versions really don't add much, since a breaking backwards-incompatible change would, by definition, always be disruptive to the user.

As with anything else words can have always different meanings and interpretations, depending on each individual, but at least the ones used in Explicit Versioning are more explicit than the ones used in SemVer.

---

One thing strikes me as awkward, but again, I'm not invested at all in this versioning system so this is just me playing devil's advocate.

Thanks for your feedback :)

Once you are not invested in this Explicit Versioning system then I think is pointless to keep an ongoing discussion about all the possible interpretations that my sentences can have, and the last thing I want to start here is a flame war about SemVer vs Explicit Versioning.