|
| 1 | +## Release Process ## |
| 2 | + |
| 3 | +### Step 1: Creating a release branch ### |
| 4 | + |
| 5 | +The branch structure in Aztec iOS is based on the [Git Flow](https://nvie.com/posts/a-successful-git-branching-model/) methodology. |
| 6 | + |
| 7 | +These are the main branches involved in the release process: |
| 8 | +``` |
| 9 | +master: Kept up to date with the latest release. |
| 10 | +develop: Bleeding edge branch with all of the latest changes. |
| 11 | +release/x.y.z: Version branch, which we will use during the release process. |
| 12 | +``` |
| 13 | +The first step in the process is creating the version branch. |
| 14 | + |
| 15 | +The version branch is what allows work to continue in develop while also having a frozen snapshot of what we’re releasing. |
| 16 | + |
| 17 | +Using the command line, the process is pretty straightforward: |
| 18 | + |
| 19 | +``` |
| 20 | +git checkout develop |
| 21 | +git pull |
| 22 | +git checkout -b release/x.y.z |
| 23 | +git push origin -u release/x.y.z |
| 24 | +``` |
| 25 | + |
| 26 | +Make sure to update the field `s.version` in both of these files to the `x.y.z` number |
| 27 | +``` |
| 28 | +WordPress-Aztec-iOS.podspec |
| 29 | +WordPress-Editor-iOS.podespec |
| 30 | +``` |
| 31 | + |
| 32 | +Open a PR on github where you target the `master` branch with the `release/x.y.z` branch and call it `Release x.y.z` |
| 33 | + |
| 34 | + |
| 35 | +### Step 2: Testing the Integration ### |
| 36 | + |
| 37 | +Before going any further, tt's normally good practice to test the Aztec integration into [WordPress-iOS project](https://github.com/wordpress-mobile/WordPress-iOS), to make sure we won’t have to do the release process twice. |
| 38 | + |
| 39 | +Make sure WordPress-iOS’s podfile specifies the SAME (and latest) commit number for both of these: |
| 40 | +``` |
| 41 | +pod 'WordPress-Aztec-iOS', :git => 'https://github.com/wordpress-mobile/AztecEditor-iOS.git', :commit => 'e0fc55abb4809b3b23b6d8b56791798af864025d' |
| 42 | +pod 'WordPress-Editor-iOS', :git => 'https://github.com/wordpress-mobile/AztecEditor-iOS.git', :commit => 'e0fc55abb4809b3b23b6d8b56791798af864025d' |
| 43 | +``` |
| 44 | +The things we want to look out for are: |
| 45 | + |
| 46 | +- That the pod can be properly installed in WPiOS. |
| 47 | +- That WPiOS builds properly. |
| 48 | +- That you can open a post through the App, using both the classic editor and Gutenberg. |
| 49 | + |
| 50 | +### Step 3: Merge the branch ### |
| 51 | + |
| 52 | +If the release PR is approved and all is working correctly in WP-iOS merge the release branch to master. |
| 53 | + |
| 54 | +### Step 4: Push the POD. ### |
| 55 | + |
| 56 | +*Automated Process* |
| 57 | + |
| 58 | +Create a new release on Github targetting the master branch and name it `Release x.y.z` |
| 59 | + |
| 60 | +Set a tag with the value `x.y.z` . |
| 61 | + |
| 62 | +On the description field and the content of the changelog for this version |
| 63 | + |
| 64 | +Press the `Publish release` button |
| 65 | + |
| 66 | +At this moment the CI automation should notice your tag and after some minutes you should get the new pod publish on CocoaPods master trunk. |
| 67 | + |
| 68 | +If this for some reason fails chech the manual process bellow |
| 69 | + |
| 70 | +*Manual Process* |
| 71 | + |
| 72 | +Pushing the PODs is a bit different than in other repos due to the fact that this repo has two podspecs. |
| 73 | + |
| 74 | +The recommended steps are: |
| 75 | + |
| 76 | +Lint the core library |
| 77 | +``` |
| 78 | +bundle exec pod lib lint WordPress-Aztec-iOS.podspec |
| 79 | +``` |
| 80 | + |
| 81 | +If all is good proceed to |
| 82 | +``` |
| 83 | +bundle exec pod trunk push WordPress-Aztec-iOS.podspec |
| 84 | +``` |
| 85 | + |
| 86 | +Then lint the Editor library |
| 87 | +``` |
| 88 | +bundle exec pod lib lint WordPress-Editor-iOS.podspec |
| 89 | +``` |
| 90 | + |
| 91 | +If all is good, push it |
| 92 | +``` |
| 93 | +bundle exec pod trunk push WordPress-Editor-iOS.podspec |
| 94 | +``` |
| 95 | + |
| 96 | +### Step 5: Closing the milestone ### |
| 97 | + |
| 98 | +For simplicity Aztec uses a single milestone named “Next Stable”. The purpose of this milestone is to be used to assign to it all of the regular issues that are closed and merged into develop during the regular development process. |
| 99 | + |
| 100 | +At this point in the release process you should rename the milestone to the version you've just released. |
| 101 | + |
| 102 | +Once renamed, you can create a new “Next Stable” milestone and assign all pending open issues to it. |
| 103 | + |
| 104 | +At this point you’re ready to close the version milestone in GitHub. |
| 105 | + |
| 106 | +### Step 6: Merge Master to develop ### |
| 107 | + |
| 108 | +Following the git Flow methodology you now need to merge the master branch back to develop. |
| 109 | + |
| 110 | +Create a new PR in GitHub that targets `develop` with the master branch. |
| 111 | + |
| 112 | +After review, if all is ok, merge that PR and your work is done. |
0 commit comments