Improve cocoapods usage

[jacobjennings]

https://guides.cocoapods.org/using/the-podfile.html
https://guides.cocoapods.org/making/making-a-cocoapod.html

Tags should be associated with podspec versions which are submitted to the master cocoapods specs repo, so instead of

pod 'SwiftProtobuf', git: 'https://github.com/apple/swift-protobuf.git', :tag => '0.9.24'

we have

pod 'SwiftProtobuf', '~> 0.9.24'

Primary pain here is that I can't make a podspec that depends on swift-protobuf unless that swift-protobuf version has an associated podspec in the Cococapods Specs repo. Looks like currently only 0.9.24 has a podspec in the Cocoapods Specs repo.

[thomasvl]

Shoot, we didn't want the spec pushed yet, like the disclaimer on the site says, we're still early in development and making breaking api changes. Looks you pushed the pod on us, can you please assign us ownership so we can take it over and manage it once the repository is ready?

[jacobjennings]

I added you as an owner and removed myself. It's completely normal to submit pre-1.0 pods to Specs, it doesn't imply it is release ready. I hope that you'll leave it in specs - using the :git tag is really a non-standard method of distribution even for prerelease state, and discourages hacking on podspecs that may want to depend on SwiftProtobuf. You can also put prerelease-state warnings in the pod description.

[thomasvl]

Thanks!

My concerns was more folks that just do ~> x.y would get updates suddenly breaking them if we keep reving things when they aren't yet stable. So by not publishing it we were hoping to avoid inflicting pain on folks.

[jcanizales]

I think that semantic versioning allows for any 0.x to 0.y update to have breaking changes. So another way of wording "avoid inflicting pain on folks" is "reducing the fun for people who like to live dangerously".

[jacobjennings]

This is true:

https://guides.cocoapods.org/using/the-podfile.html
http://semver.org

In my experience people most often use the "optimistic operator ~>" to get automatic patches (0.1.1 -> 0.1.2) and selectively upgrade minor versions (0.1.1 -> 0.2.0)

[thomasvl]

#579 includes a commit to update the README.md to not need the git url as I've pushed the pod since we're hopefully closing in on a release. That PR also includes notes for our process of doing release so we should do the pod pushes going forward.

[thomasvl]

Closing this out, as I believe we're pushing the pods with releases now.