过去和原因

很多人问，为什么CocoaPods发布Pods没有一种简单的方式，就像RubyGems、NPM等工具那样。所以，今天我们将用一种更好的发布方式。

可以说，配置像Xcode这样的黑箱，为各个平台 获取本机代码进行编译，部署目标，以及架构的建立和布置都是比诸如RubyGems,NPM之类的工具困难。很显然，脚本语言不用处理这些复杂的工作。

所以，我之前开发CocoaPods的时候，由于我们甚至不清楚核心业务的细节，以至于我不想将太多精力集中到网络服务上。即便你能够在一个周末之内创造一个网络服务来，但并不意味着这对解决那些复杂工作（即解析、安装、整合你的依赖）有什么帮助。

事实上，从网络服务开始会使得整个过程更为复杂。因为运行一个网络服务意味着你现在突然间去必须维护它，社区则希望它一直保持运行状态。如果说我学会了什么的话，那就是作为志愿者的责任。志愿者们用他们的业余时间无偿的做这件事情，不可避免的是这些资源终将殆尽，需要筹集很多钱来应对可能的困难。（其中一些例子是RubyGems.org志愿者们对于宕机时间和scalenpm.org志愿者们对于维护基础设施所需大量资金所面临的巨大压力。）

我也想设计这样的体系结构，例如，企业想通过CocoaPods使用他们的私有依赖将不必配置和也不必建立一台主机来提供网络服务。没有人愿意做这些额外的工作，并不仅仅因为那些服务器管理的失败经历。

由于这些原因，这个简单的解决办法是用一个简单的目录结构和已建立的SCM系统来维护已发布的版本和简单的发布新版本。这种简单的策略对于我们来说也不错。然而，在一定规模，特别是在诸如master’ spec-repo这样一个开源环境里面，不可避免地需要将它发展到更高的水平。

问题

我们的‘master’ spec-repo老大——KeithSmiley先生，是一个评审与合并达人，在这两年，他能够立即响应你们发送的pull-requests。但是，就像我们清楚看到的那样，发布的Pods与日俱增，已经到了Keith不能掌控的程度。

另一个问题是我们注意到现在创建一个pull-request的工作流程和自动从Travis得到反馈，除了由Keith手动审核。Paul让很多podspec发布者变懒，而不是适当地在自己的应用测试podspec是否配置正确。他们直到它使用时才更新和发布他们的specs。这不仅是对志愿者们时间的浪费，也转移了验证podspecs是否有效工作的责任。

社区另外一些人想为CocoaPods创造网络服务，为此他们需要一些接口和其他格式的文件而不是ruby。这样才能理解podspecs，并且提供更好的服务。

最后，某种程度上，即使是心肠最好的人都会滑倒。一个很好的例子就是，当一个没有认证的人位一个不存在的AFNetworking版本发布一个podspec。显然，唯一能这样做的人只有Matt（AFNetworking的作者）和Matt所信任的其他维护者。

解决办法是什么呢？一个自动的网络服务和一个用ACL层注册了所有者的数据库，这个数据库允许指定的人发布新版本。

‘Trunk’，我们的解决方案

生长在树干上的不同成熟度的Cocoa Pods。

今天，我们发布我们的网络服务来解决前面所提到的问题。'Trunk'网络服务的引进意味着发布者现在能够通过命令行直接发布Pods，而不需要创建pull-request。

第一个自动发布pod的人在‘master’spec-repo范围内获得pod名所有者的认证。所有者能够添加其他的他认为合适的所有者。只有这些所有者能够发布版本。要获得更多这方面的信息以及和Trunk的相互关系请看向导。

请注意，我们依然维持着github相同仓库上可用的pods和他们的说明。这意味着如果某些问题影响数据库的运行和稳定性，我们的用户依然能够依靠github全天候的专业支持。这样，如果Trink由于不明原因宕机了，我们的普通用户不会受到影响，仅仅所有者在那期间不能发布新pods。总之，这对你来说意味着能够使用更稳定的工具，对我们志愿者来说意味着更少的压力。下图展示了我们的架构概览。

至于确保podspec正确的工作是作为所有者的你唯一的责任。我们仅仅在后端用公开的最小元数据验证你的podspec，当然前提是你要注册你的podspec。我们将不在Travis上验证你的podspec。我们将不接受没有严格审查过程来发布podspecs的更新（通过在‘master’spec-repo执行的pull-request）。这样，在你发布一个podspec前在你的真实项目或者demo里测试将更可能被推荐。

最后，Trunk网络服务将不再存储ruby格式的podspecs。取而代之的是存储json格式。这样CocoaPods生态圈的人能够将json格式用在其他网络服务上。

迁移

我们将有一个宽限期来让现在所有pod的所有者将各自的pod转换到Trunk网络服务上来。pod在转换期间不可用，直到我们满足了大多数重要pod。更多关于pod的要求请阅读Keith的博客。

常见问题

我得到一个”目前不可访问的消息“，什么问题呢？

在声明期间，pod trunk push将不可用。请看迁移部分。

我能够修改已发布的podspec吗？

一旦一个确定版本的podspec被发布，你就不能再修改了。至少不是自动的方式。大多数更新请求是发布者没有在发布之前有效测试podspec导致的。你可以发布新版本，但是不能更改已经发布的版本。然而，如果你真的由于某些特殊原因导致需要修改podspec，你可以再次在master’spec-repo创建一个pull-request。但是我们不必接受它，也不保证解决时间。

我怎样区分一个podspec的格式？

通过后缀名区分，podspec后缀为.podspec，json后缀为.podspec.json。

基于ruby的spec会被废弃吗？

不会，如果你需要自动生成，还会是这个格式，比如收集你磁盘上源文件的列表。 pod trunkpush命令会小心地将podspec格式转换成json。这意味着你不必改变现存的posspec。

私有仓库需要采用json格式吗？

不需要。此外，pod push命令会保持之前的格式，除非我们正在将其转移到pod repopush命令来强调区别。仅仅记住如果两个文件在cocoaPods都是可用的话，json当然最好。

我能通过http接受spec吗？

能够，你能使用github接口。我们将引进Trunk的公共接口，你能用来标准化它。但是要注意的是，如果你不需要github提供的接口之外的接口，最好还是用github的。毕竟github能够提供比我们更好的实时功能。

得到可用pod列表:

https://api.github.com/repos/CocoaPods/Specs/contents/Specs

得到某一pod的可用版本:

https://api.github.com/repos/CocoaPods/Specs/contents/Specs/ObjectiveSugar

获取某一pod版本的spec:

https://api.github.com/repos/CocoaPods/Specs/contents/Specs/ObjectiveSugar/0.9/ObjectiveSugar.podspec.json