Look at the wording around Semantic Versioning about guides.cocoapods.org

[drewcrawford]

As the author of that piece, I would like to expand on that point a little.

Intelligent people can disagree about the wisdom of SemVer. There is a long blog battle spanning multiple volumes about this with some good points on all sides that is far outside the scope of this issue.

However when a package manager starts insisting on SemVer that is a unique and particular problem that has historically been a recipe for trouble.

For example, underscore had a rather large kerfuffle because npm enforced a semver-based-versioning-scheme on a project maintainer that actively didn't want it, and the stubbornness on both sides of the line caused lots of code to break for real people, involved forks, and all kinds of drama. Man-weeks were lost.

Given the experience that other package managers have had on this issue I think it would be wise to accept the reality, that we are not all of one mind about how to version packages, that we will never be of one mind. And so let's talk about how we can plan around that difference in perspective rather than trying to get everybody to agree on the One True Way.

[alloy]

@orta Indeed, the wording could use clarifying. CocoaPods does not require SemVer at all. People can use any version format that would like to use, just not ‘arbitrary revisions’, e.g. a git commit sha hash.