Look at the wording around Semantic Versioning

[orta]

http://sealedabstract.com/rants/on-ios-packaging/

However CocoaPods goes far beyond being opinionated about your build process. They have some kind of religion about using the RubyGems versioning system (Yes, for iOS libraries. wat.) Then they require you to update your list of source files in 2 places, because parsing Xcode’s format is too hard I guess?

The wording around versioning makes sense if you come from a ruby background but should be given a second look from the perspective of a Cocoa developer. We don't use SemVer cause bundler does, though we kinda do, but because semantic versioning is a standard that makes it easy for people to understand when something is worth updating or not.

[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.