2016 年 5 月 10 日
关注 @segiddins我非常高兴地说，经过四年半的令人难以置信的开发，我们刚刚发布了 CocoaPods 1.0。走到这一步的道路很漫长，但这段旅程讲述了更大的 Cocoa 开源社区的故事——从 Xcode 的新版本到新的语言和平台，CocoaPods 多年来不断发展，以支持数量惊人的开发人员。
在我们的所有不同项目中，我们积累了大约 400 位开发人员提交的约 20,000 次提交，关闭了约 22,000 个问题——这确实是一次社区努力，才得以达到约 19,000 个 pod和约 86,000 个版本。通过此版本，我们承诺保持 CocoaPods 稳定，并承诺它已准备好用于生产（请参阅此条目在我们的常见问题解答中，我们已经迫不及待地想要删除多年）。
自添加统计数据一年以来，我们对CocoaPods 影响的规模有了真正的了解。CocoaPods 已被用于将约 285,000,000 个 pod 集成到约 850,000 个独特的 Xcode 目标中。
更改
让我们先了解 1.0 中的更改。我们遵循的首要原则是为 CocoaPods（该工具）做好未来五年的准备，而不是引入任何单独的功能。CocoaPods 是许多人依赖于完成其工作的工具，我们不会轻视这种信任——我们决定一次性进行重大更改，这样我们就不需要再进行很长时间了。
以下是 1.0 版本的亮点，但自我们上次小版本发布 0.39 以来已经过去了七个月（其中四个半月是 1.0 beta 阶段）。正如你可能想象的那样，我们积累了很多大大小小的更改，你可以在CHANGELOG中找到所有 750 个提交的摘要。（CocoaPods 组织下其他项目的 CHANGELOG 同样详细说明了我们在此期间所做的所有其他更改。）
Podfile DSL
到目前为止，最大且最具颠覆性的更改是我们改变了 Podfile 的工作方式，使其与我们开发 Cocoa 应用程序的方式更好地保持一致。几个月前，我们发布了一个迁移指南，详细说明了大部分更改——我们预计大多数人将在不到十分钟的时间内迁移最复杂的 Podfile。
以下是重点内容
所有目标都必须在 Podfile 中明确定义，并且它们的名称必须与 Xcode 中的目标名称相匹配。
某些命令行选项已移至 Podfile 安装选项。
有一个新的 目标继承选项，旨在允许测试目标仅继承应用程序目标的搜索路径。
抽象目标现在已成为现实。这使得跨平台共享依赖项不再那么重复。
改进的 Linter
CocoaPods 提供的一项不错的功能是能够对 pod 进行 lint，确保 Podspec 格式正确，并使用户确信他们正在集成的库可以为 Podspec 中声明的平台编译。在 1.0 中，我们走完了最后一步 -- pod 将被编译并导入到实际应用程序中，以确保不会出现奇怪的构建或导入错误。
改进的源处理
正如我们 上周发布的那样，我们对处理更新源的方式进行了重大改进，以确保 Specs 存储库保持快速、可用和一致。我们很高兴这个问题在 1.0 之前浮出水面 -- 它给了我们重新审视在 CocoaPods 达到当前规模之前做出的某些假设所需的动力，并且从长远来看应该提供更好的用户体验。
自动解耦
更改 Podfile 中的目标在 Xcode 中进行构建时不再会导致中断。我们还将 cocoapods-deintegrate 设置为默认插件，并且 pod install 现在将确保任何未与 CocoaPods 集成的目标都已删除 CocoaPods 的所有痕迹。
锁定 CocoaPods 主规范存储库
大约两年前，当我们宣布 trunk时，我们开始锁定CocoaPods master specs 存储库的过程。随着 CocoaPods 1.0 的推出，我们对该工作进行了政策更改 -- 我们将不再接受对 specs 存储库的请求。为了确保 pod 所有者仍然拥有完全控制权，我们引入了pod trunk deprecate和pod trunk delete命令。虽然我们强烈建议不要从 specs 存储库中删除 podspecs，但我们已将该决定权交给了 pod 所有者。
过去五年
CocoaPods 始于大约五年前，作为一个由Eloy Durán发起的项目，灵感来自 Bundler 和 RubyGems，而不是 Apple 提供的任何系统。
鉴于 CocoaPods 无法控制底层工具链，Cocoa 生态系统一直是运行依赖项管理器的有趣场所。它产生了一些有趣的问题，偶尔还会产生噩梦。去年，Apple 已进入该领域，推出了Swift Package Manager，我们对它对整个社区的意义非常乐观。
CocoaPods 不会很快消失 -- 我们倾注了我们的心血在这个项目中，并且非常感谢团队成员和所有用户投入的时间和爱。在一个具有如此远大抱负的项目上工作是一件令人兴奋的事情，人们选择相信它用于他们的日常工作。只要你们都在使用 CocoaPods，我们将继续努力改进它。1.0 只是该道路上的第一步。
感谢
正如我之前提到的，CocoaPods 非常感谢我们的整个社区，因为 CocoaPods 一直是社区的反映。如果没有每个人的参与，这一切都是不可能的。
然而，我特别要感谢一些人，因为如果没有他们的时间，CocoaPods 永远无法达到 1.0。
Eloy Durán
Eloy 发起了 CocoaPods，并且众所周知是我们的“最终 boss”。除了他对项目创立的愿景之外，Eloy 还足够勇敢地让其他人接手并成为领导者。他建立了团队文化，并且仍然经常积极参与，从帮助解决问题到为Mac 应用程序构建基础。
Fabio Pelosin
Fabio 是 CocoaPods 的旋风人物——他没有任何 Ruby 经验，但在几年时间里构建了今天仍然存在的许多基础设施。Fabio 仍然是提交 CocoaPods 项目次数最多的人，这个头衔在很长一段时间内都不会被夺走。在早期处理数千个 GitHub 问题时，他提供了如此多的正能量。
Orta Therox
Orta，我们的设计独裁者，最初通过维护 Specs Repo 上的拉取请求加入 CocoaPods 团队，在我们引入 Trunk 之前。他对社区的第一个重大贡献是通过 CocoaDocs，它为所有 pod 生成文档。从那时起，他的工作围绕着面向公众的 Web 基础设施、Mac App、社区管理和设计。
Florian Hanke
Florian 是此列表中唯一从未制作过 Cocoa 应用程序的开发者。他在五年前加入团队，此前在日本遇到了 Eloy，并一直致力于 CocoaPods 的搜索引擎。他在创建 Trunk 方面发挥了基础性作用，并且仅仅因为喜欢与团队在一起，就帮助处理了所有 CocoaPods Web 基础设施。
Kyle Fuller
除了担任将近一年的发布经理外，Kyle 还帮助在 CocoaPods 中设置了重要的流程。通过帮助我们将 CocoaPods 的核心拆分为插件，并致力于通过 CI、RuboCop 和 Rakefiles 管理微型项目的必要工具，Kyle 为 CocoaPods 的内部项目管理奠定了基础。
Marius Rackwitz
Marius 将自己定位为一个最困难的入门项目工作——为 CocoaPods 构建框架支持。实际上，这是一个多年的项目，随着平台的演进，边缘案例仍然不断出现。
Boris Bügling
Boris 投入了大量的精力来确保 CocoaPods 支持现代 Cocoa 应用程序中使用的令人眼花缭乱的平台、目标类型和 Xcode 项目设置。此外，他一直是我们一致的三级大师，致力于控制我们的问题。
Samuel Giddins
就是我！我会尽力不吹嘘，但鉴于我按下了按钮（或在终端中键入一堆深奥的命令）实际上发布了它，我想我会把自己添加到列表中。自大约两年前加入 CocoaPods 核心团队以来，我花了无数个小时来实现疯狂的新功能并调查最奇怪的错误。这真是太棒了，而 CocoaPods 此时已成为我生活中的重要组成部分。我期待我们这个小项目中的下一个 3000 次提交。
赞助商
除了所有为该项目贡献时间和专业知识的人之外，在过去几年中，我们还以各种方式获得了慷慨的赞助。首先，我要感谢 Capital One，他们自 10 月以来一直赞助我，从而支持了自那时以来完成的大部分 1.0 特定工作。此外，如果我们不感谢 Artsy、Button、Discontinuity、Fingertips、Heroku、Realm、RubyMotion、Sauspiel、Segment、Slack、SoundCloud、Stripe 和 Technology Astronauts 多年来对我们的赞助，那将是一种疏忽。没有他们的支持，CocoaPods 生态系统根本无法以今天的形式存在。
让我们庆祝
在过去两年中，CocoaPods 一直是我生活的重要组成部分。我知道现在只是说终于很诱人，但我认为这是一个更有意义的机会——这是一个让我们作为社区庆祝的机会。CocoaPods 不仅仅是一个工具——它是一个由出色的 iOS、Mac、watchOS 和 tvOS 开发人员组成的社区。它是一个由敬业的贡献者组成的团队，他们通过回答问题和提出请求自私地回馈。在过去的两年里，CocoaPods 一直是我的家，在我们的 1.0 版本发布之际，我认为是时候庆祝了。未来一片光明，我们已经经历了一段伟大的旅程才走到这里。现在让我们吃点蛋糕，享受这一刻。
