创建自己的 CocosPod

创建你自己的 CocoaPod 非常简单。 如果你已经有了一个单独的组件, 本指南的整个过程的概述,就是最好的选择。 本节中的其他指南更深入地为更高级用户提供服务。

我们建议让 CocoaPods 做复杂的工作。 运行 pod lib create [pod name] 将为您设置一个经过深思熟虑的库结构,使您能够轻松包含文件并快速入门,我们为此提供了指导。 如果您想要了解整个流程的最新演练,并推送到主干(pushing to trunk),请查看 tutorial 的第三方教程。

Pod 文件

CocoaPod 和一个通用的开源库只有一些区别。 除了实际来源外,最重要的是 .podspecLICENSE。 没有代码许可证,我们不接受图书馆进入干线(trunk)。 有关可选择许可证的信息,我们建议阅读this article on CodingHorror or tl;dr Legal.

开发

您可以在系统上的文件夹中处理库。

或者,您可以使用 :path option: 的选项 从应用程序项目开始工作.

pod 'Name', :path => '~/code/Pods/'

测试

您可以通过将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 => '../'

发布

准备好发布后,您需要制作相应的标签。 首先运行一个快速的 pod lib lint ,然后创建你的标签(tag)并推送(push)它。

发布工作流程类似于以下内容。

$ 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
  • 提交开源代码
    一旦你的标签被 push,你可以使用下面的命令:
    pod trunk push NAME.podspec
    
    把你的 library 发送到 Specs repo。 有关获取此设置的更多信息,请参阅Getting Setup With Trunk.
  • 提交私人代码
    一旦你的标签被 push,你可以使用下面的命令:
    pod repo push [repo] NAME.podspec
    
    把你的 library 发送到指定的私人 Specs repo 。请参阅 Private CocoaPods.

库版本控制

不幸的是,开发人员通常不会很好地解释版本号,或者为某些版本号分配情感值(emotional value)。

在 library 的管理中, 正确恰当的版本号要优于随意的版本号 (请参阅Semantic Versioning
). 让我们解释一下,在我们设想的功能中,我们更喜欢人们与它互动:

  • “我想开始使用 CocoaLumberjack 库,目前的版本还可以使用。”因此,开发人员在没有版本要求的情况下添加了对 lib 的依赖关系,并且将使用最新版本的pod安装:

    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安装即可,否则,如果他们必须手动更改所有内容,他们可能会做得更少。 CocoaPods使用较不严格的语义版本,因为它不会强迫你使用X.Y.Z,你可以使用X.Y版本。

CocoaPods 版本控制细节

CocoaPods版本控制SCocoaPods使用RubyGems版本来指定版本。RubyGems Versioning Policies
描述了用于解释版本号的规则。 RubyGems version specifiers 描述了如何使用指定依赖项版本特定的比较运算符.

遵循 RubyGems 中建立的模式,预发布版本也可以在 CocoaPods 中指定。 例如,版本1.2的预发布可以由1.2-beta3指定。 在这个例子中,依赖说明符〜> 1.2-beta将匹配1.2-beta3。

谷歌有一个关于它如何工作的视频:"CocoaPods and the Case of the Squiggly Arrow (Route 85)".

记录 Pod

现在,获取有关记录 Pod 的信息的最佳位置是 NSHipster 关于 Obj-C 和 Swift 文档的博客文章。 CocoaDocs将在推送后大约15分钟的时间内发布基于 Podspec 公共 API 的 appledoc / jazzy 分析代码。 关于 CocoaDocs 的更多信息可以在 CocoaDocs 开发者自述文件中找到.

你可能感兴趣的:(创建自己的 CocosPod)