This guide is for maintainers of optable-ios-sdk
and lists the steps required when releasing a new version to third-party developers.
Create a branch with the upcoming release number as its name and publish it to GitHub. Create a draft pull request from the branch (example: 0.10.0
).
Commit release-related changes, such as updating MARKETING_VERSION
, into the release branch.
The release branch will also enable you to run pod spec lint
once you've updated the OptableSDK.podspec
file to reference the new upcoming release number, since spec lint
clones the code from GitHub and looks for a branch or tag that matches the release number.
One of the supported installation methods for the SDK is CocoaPods, so you'll want to make sure that you have it installed and updated if you are preparing a release.
Make sure your local ruby
is up to date and that you are using the latest stable release. It is recommended that you use rvm to install and manage your local ruby versions.
Refer to the CocoaPods Getting Started Guide to learn how to install.
If it has been some time since you've last updated CocoaPods, once you've updated your local gems you can run bundle update
from the project's top-level directory. This will update all ruby dependencies that are bundled when CocoaPods is run.
More information regarding bundler update can be found here
If there are changes to the Gemfile or Gemfile.lock, make sure that you commit them to the release preparation branch.
Open OptableSDK.xcodeproj in XCode and navigate to OptableSDK
under the project's build targets, then to the "General" tab where you will find a "Version" input field. Update this field value to the upcoming release number (example: 0.10.0).
This field is sometimes called the MARKETING_VERSION
and you should see a diff to OptableSDK.xcodeproj/project.pbxproj
file once you save your change.
Make sure to commit your changes to the release preparation branch.
Make sure that the OptableSDK.xcodeproj
build completes successfully, and that you can complete the following steps within XCode without errors:
- Product > Clean Build Folder
- Product > Build
- Product > Test
Update the spec.version
field value in the OptableSDK.podspec to refer to the upcoming release (example: 0.10.0).
Commit your changes to the release preparation branch and push them upstream to GitHub.
Run pod lib lint
and ensure that it completes successfully.
Finally run pod spec lint
and ensure that it completes successfully.
The demo apps in demo-ios-objc and demo-ios-swift make use of CocoaPods to manage their dependency on the SDK. You will notice in each of their Podfiles
that they refer to the OptableSDK
pod using a :path
parameter -- this means that they will look for the OptableSDK.podspec
in their parent directory locally, and not try to download the pod from the official cdn.cocoapods.org
repository.
This allows you to update the demo apps to the latest SDK version and run tests simply by changing into the demo app directory and running pod install
and pod update
. Once you've run pod update
in the demo app directory you may notice changes to the Podfile.lock
so make sure to commit those to the release preparation branch.
You should see a demo-ios-{swift,objc}.xcworkspace
file locally in the demo app's directory after you've done a first pod install
. Open the xcworkspace
file in XCode and make sure that it builds cleanly and that you can run the demo app in the iOS simulators and that it is functioning as expected.
Ensure all release preparation changes have been committed and pushed to the release preparation branch and that the draft PR passes all required checks, including the automated CircleCI builds.
Once the PR is ready, squash and merge it into master
and delete the release preparation branch.
Ensure that the latest merged changes successfully pass all automated CircleCI builds in master
.
Draft a new release in the GitHub Releases page, specifying a new tag for creation with the tag name equal to the version of the release (example: 0.10.0). The release title should also be set to the release version number, and the description should include a list of important changes since the previous release. Publish the release.
Ensure that the CircleCI release-builds which will run automatically when the release tag is published complete successfully.
In order for third-party application Podfiles
that reference the OptableSDK
pod on cdn.cocoapods.org
to correctly install the latest released version of the SDK when developers run pod install
, you'll need to push the latest OptableSDK.podspec
to the CocoaPods public trunk repository.
You will first need to register with the CocoaPods trunk repository. You can do this by following the CocoaPods guide here. If not already done, and once registered, an existing optable-ios-sdk
maintainer will need to add you as a contributor by running pod trunk add-owner OptableSDK [email protected]
.
Authorized contributors can then run pod trunk push
from the project's top level directory which will run pod spec lint
automatically and, on success, publish the new OptableSDK.podspec
to the public repository. Before running pod trunk push
, make sure to git pull
the latest master
branch, containing the latest changes as well as the newly published release tag.