[TOC]
创建你自己的 CocoaPod 非常简单。 如果你已经有了一个单独的组件，那么你就是最好的选择。 本文概述整个过程，本节中的其他指南可为高级用户提供更深入的了解。
我们建议让 CocoaPods 在这里努力工作。 运行 `pod lib create [pod name]` 将为您设置一个经过深思熟虑的库结构，使您能够轻松包含文件并快速入门，我们为此[提供了使用指南](https://guides.cocoapods.org/making/using-pod-lib-create)。 如果您想要了解整个流程的最新演练，并推送到主干，请查看 tutsplus 的[第三方教程](http://code.tutsplus.com/tutorials/creating-your-first-cocoapod--cms-24332)。
# 1. Pod 文件
CocoaPod 和一个通用的开源库只有一些区别。 除了实际来源外，最重要的是 .podspec 和 LICENSE 。 没有代码许可证，我们不接受代码资源进入干线。 有关可选择许可证的信息，我们建议阅读 [CodingHorror](http://www.codinghorror.com/blog/2007/04/pick-a-license-any-license.html) 或 [tl; dr Legal](http://www.tldrlegal.com/) 上的这篇文章。
## 1.1 开发
您可以在系统上的本地文件夹中使用库。或者，您可以使用 `：path` 选项从应用程序项目开始工作：
~~~
pod 'Name', :path => '~/code/Pods/'
~~~
## 1.2 测试
您可以通过将 pod 与其目录的文件相关联来测试 Podfile 的语法，但这不会测试 linting 的下载方面。
~~~
$ cd ~/code/Pods/NAME
$ pod lib lint
~~~
在将新 Pod 发布到世界之前，最好测试一下，可以成功将您的 Pod 安装到 Xcode 项目中。 可以通过以下几种方式来完成此操作：
将 podspec 推送到您的仓库，然后使用 Podfile 创建一个新的 Xcode 项目，并将您的 pod 添加到文件中，如下所示：
~~~
pod 'NAME', :git => 'https://example.com/URL/to/repo/NAME.git'
~~~
然后执行
~~~
pod install
-- or --
pod update
~~~
或者，如果您的单元测试有单独的 Xcode 项目，则可以使用此项目的 Podfile 来引用您的开发 podspec
~~~
xcodeproj 'NAMETests'
workspace '../NAME'
pod 'NAME', :path => '../'
~~~
## 1.3 发布
准备好发布后，您需要制作相应的标签。 首先运行一个快速的 `pod lib lint`，然后创建你的标签并推送它。
发布工作流程类似于以下内容。
~~~
$ cd ~/code/Pods/NAME
$ edit NAME.podspec
# set the new version to 0.0.1
# set the new tag to 0.0.1
$ pod lib lint
$ git add -A && git commit -m "Release 0.0.1."
$ git tag '0.0.1'
$ git push --tags
~~~
### 1.3.1 提交开源代码
一旦你的标签被推送，你可以使用命令:
~~~
pod trunk push NAME.podspec
~~~
将您的代码资源发送到规范资源库。 有关获取此设置的更多信息，请参阅 [Getting Setup With Trunk](https://guides.cocoapods.org/making/getting-setup-with-trunk)。
### 1.3.2 提交私人代码
一旦你的标签被推送，你可以使用命令:
~~~
pod repo push [repo] NAME.podspec
~~~
把你的代码资源发送到指定的规范资源库。 有关获取此设置的更多信息，请参阅 [Private CocoaPods](https://guides.cocoapods.org/making/private-cocoapods)。
# 2. 库版本号
不幸的是，开发人员通常不会很好地解释版本号，或者为某些版本号分有意义的值。
然而，版本的任意修改对于图书馆管理员来说并不是一个好主意，而不是适当的版本号（请参阅[语义版本控制](http://semver.org/)）。 让我们解释一下，在理想的世界里，我们更喜欢人们与它互动：
* “我想开始使用 CocoaLumberjack，目前的版本现在还可以。”因此，开发人员在没有版本要求的情况下添加了对lib的依赖关系，并且将使用最新版本的 `pod install`：
~~~
pod 'CocoaLumberjack'
~~~
* 在未来的一段时间内，开发人员想要更新依赖关系，然后再次运行 install 命令，该命令现在将安装当时最新版本的lib版本。
* 在某些时候，开发者已经完成了客户端工作（或者更新版本的lib改变了API并且不需要这些改变），因此开发人员向依赖关系添加了版本需求。 例如，考虑到lib的作者遵循semver指导原则，你可以相信'1.0.7'和'1.1.0'之间不会进行API更改，但只会修正错误。 因此，不需要特定的版本，开发人员可以指定任何'1.0.x'只要高于'1.0.7'就被允许：
~~~
pod 'CocoaLumberjack', '~> 1.0.7'
~~~
关键是开发人员可以轻松跟踪更新版本的依赖关系，只需再次运行 `pod install` 即可，否则，如果他们必须手动更改所有内容，他们可能会做得更少。 CocoaPods使用较不严格的语义版本，因为它不会强迫你使用X.Y.Z，你可以使用X.Y版本。
## 2.1 CocoaPods版本控制细节
CocoaPods 使用 RubyGems 版本来指定pod规范版本。 [RubyGems 版本管理策略](http://guides.rubygems.org/patterns/#semantic-versioning)描述了用于解释版本号的规则。 [RubyGems 版本说明符](http://guides.rubygems.org/patterns/#declaring-dependencies)精确地描述了如何使用指定依赖版本的比较运算符。
遵循RubyGems中建立的模式，预发布版本也可以在CocoaPods中指定。 例如，版本 1.2 的预发布可以由 1.2-beta3 指定。 在这个例子中，依赖说明符 `〜> 1.2-beta` 将匹配 1.2-beta3 。
# 3. 记录 Pod
现在，获取有关记录 Pod 的信息的最佳位置是 NSHipster 关于 [Obj-C](http://nshipster.com/documentation/) 和 [Swift](http://nshipster.com/swift-documentation/) 文档的博客文章。 [CocoaDocs](http://github.com/cocoapods/cocoadocs.org) 将在推送后大约15分钟的时间内发布基于 Podspec 公共 API 的 appledoc / jazzy 分析代码。 关于 CocoaDocs 的更多信息可以在 CocoaDocs [开发者自述文](http://cocoadocs.org/readme)件中找到。
# 4. 我可以在哪里提问？
* [Stack Overflow](http://stackoverflow.com/search?q=CocoaPods)：这样就可以减少 CocoaPods 开发团队的压力，并让我们有时间在项目上工作，而不是支持。使用 Stack Overflow 的优点之一是，对于其他人来说，答案很容易访问。
* [CocoaPods Mailing List](http://groups.google.com/group/cocoapods)：邮件列表主要用于相关项目的公告和支持。
# 5. 外部资源
* [为什么你的 podspec 失败了](http://codeslingers.co.uk/2014/05/16/why-your-podspec-is-failing/)
