By removing the version here, we're saying that any version of CMDQueryStringSerialization should work with this repo. If a user declares pod 'CMDQueryStringSerialization', '~> 0.2.0' in their Podfile and include this latest version of VENCore that includes this change with no version restriction, there may be some issues in resolving the appropriate dependencies.

I'm really not for removing version requirements in podspecs, although it may be fine in Podfiles.

That's true. We only use the library in one place: https://github.com/venmo/VENCore/blob/master/VENCore/Networking/VENHTTP.m#L110

Maybe we can just use the implementation, so VENCore has 0 dependencies

@eliperkins so the reason for this is I want to use version 0.3.0 in the Venmo app. I spoke with @calebd and he ensured me that the public API for serialization wouldn't change. To use 0.3.0, I had to remove the version restriction in VENCore, then update one of our private pods that had a version restriction on VENCore and then update all three in our app's Podfile. If we know this API won't change, I think it's best to be able to update it independently.

That said, @dasmer, if we only use it in one spot, maybe it's worth adding that specific category so we don't have an dependencies on something that should be super portable.

What do you guys think?

Since this repo is public, and our iOS SDK depends on it, I'm 👎 in general on removing versions from dependencies to keep things simple for peeps who consume our stuff. If we wanna bring simple query parsing into this repo, that's cool with me, except that the iOS SDK is gonna use it on one line too: https://github.com/venmo/venmo-ios-sdk/blob/master/venmo-sdk/Venmo.m#L336

Don't feel too passionate on removing the dependency, especially since we only use it twice in this path. I do feel pretty passionately about destroying dependency version resolution :P

I'm kind of OK either way. It's a hassle to update all the Pods with every version bump.
Also, technically since the major version is 0, there can be breaking changes in any version updates.

@calebd if the public API is finalized and permanent, any reason not to release 1.0.0?

Thinking about it more, I think it's a bad idea to remove @calebd's library if we need query string parsing. This junk is complicated and he has done a fanatic job handling all of the edge cases and writing tests for it. I definitely don't want to maintain that.

Totally down to lock to a version. If we need to update it (assuming we won't often), we can just bump the version of all of our junk.