🔥码云GVP开源项目 12k star Uniapp+ElementUI 功能强大 支持多语言、二开方便! 广告
[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/)