TRCL-2984 : Create 3P Suggested Release Instructions doc #23
Conversation
mike-dydx
changed the title
mike-dydx
force-pushed
the
mike/trcl-2984-create-3p-suggested-release-instructions-doc
branch
5 times, most recently
from
445e737
to
82a3fdf
Compare
mike-dydx
force-pushed
the
mike/trcl-2984-create-3p-suggested-release-instructions-doc
branch
from
82a3fdf
to
c55d5e5
Compare
| <key>ITSAppUsesNonExemptEncryption</key> | ||
| <false/> |
There was a problem hiding this comment.
adding this prevents us from having to manually indicate the apps exemption for app store encryption policy
| @@ -0,0 +1,80 @@ | |||
| fastlane documentation | |||
There was a problem hiding this comment.
this is a generated file, can ignore
docs/branching_strategy.md
Outdated
| git checkout -b release/1.0.2 | ||
| ``` | ||
| 3. Implement and test the fix rigorously on the hotfix branch. | ||
| 4. Merge the hotfix branch into `main` and deploy to production. |
There was a problem hiding this comment.
Having the hotfix merged into 'main' can be confusing. For instance, if 'main' already contains the changes for version "1.1", and when a hotfix 1.0.2 is merged into 'main', it would be tagged after '1.1'.
I think it's better to just merging to 'develop' and let 'main' as-is. The change in the hotfix will be merged to 'main' when 'develop' gets merged to 'main' at some point in the future (i.e., when the next release happens).
There was a problem hiding this comment.
I see what your saying, but I am curious if that is actually a reachable scenario.
If main already has 1.1 tag merged in, then we should have a release/1.1 branch and the hotfix release branch should then be release/1.1.1 if the hotfix is coming after the 1.1 changes were merged in.
In the other case, if we begin the hotfix work before 1.1 is released, then the 1.1 release should be paused until after the 1.0.2 hotfix is merged into develop & main
There was a problem hiding this comment.
Yeah.. I think there could be scenarios where we need to support multiple releases. Some deployer might want to stay with 1.0 but ask us to fix some issue on 1.0, and meanwhile we have already moved on to 1.1.
There was a problem hiding this comment.
My feeling is that if a deployer wants to persist an older version, they should cherry pick hotfix commits, or modify their own fork with the hot fix changes. Otherwise, we must apply all hotfixes in a backwards way and I think that would be a large drain on resources. If anything, we should encourage users of our code to stay up-to-date rather than support out-of-date versions.
Consider this example: if we're on version 5.0.0, but we realize that 1.0.0 has a issue we want to fix, that means all version between 5.0.0 and 1.0.0 need to have the fix applied so that we support all versions.
There was a problem hiding this comment.
In my mind, having hotfixes implies that we support multiple release versions. Otherwise, if we only support the current version, then there is no need of hotfix or release branches. We can just apply the fix on 'main', and create a new release.
The hotfix should be a minimal change to address a specific issue on a release. The current version (on 'develop') should be our focus, so it makes sense to merge it there. We can merge it to other releases as see fit.
In any case, I think the chance of having to do a hotfix is pretty small since most deployer will stick with the latest version.
There was a problem hiding this comment.
Let me know what you think of this to support the scenario you originally mentioned
mike-dydx
deleted the
mike/trcl-2984-create-3p-suggested-release-instructions-doc
branch
* add 3p deployment instructions * address comments * Update Info.plist * Update marketing_url.txt
* add 3p deployment instructions * address comments * Update Info.plist * Update marketing_url.txt
* add 3p deployment instructions * address comments * Update Info.plist * Update marketing_url.txt
Links (dYdX Internal Use Only)
Linear Ticket: TRCL-2984 : Create 3P Suggested Release Instructions doc and get legal sign off
Description / Intuition
In order for a third party to deploy their own forked app, we must make it simpler to deploy. This PR creates fastlane lanes and Bitrise config files for deployment and release. A deployer can choose to use fastlane, Bitrise, or Xcode's built in tooling.
New lanes available:
update_bundle_identifier - Update PRODUCT_BUNDLE_IDENTIFIER in Xcode project with the app_identifier from the Appfile
dydx_increment_build_number - Increments the build number based on last build submitted to testflight
update_marketing_version - Update the marketing version in the Xcode project
generate_app_icons - Generate app icons
create_build_and_submit_for_review - Submit a new build for review
Also in this PR is a new readme describing our strategy for branching, releases, and hotfixes.
App Icons were generated by fastlane from a single 1024x1024 image. This will reduce file name conflict for 3rd parties using fastlane to generate app icons going forward.
Type of Change