[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/)