TRCL-2984 : Create 3P Suggested Release Instructions doc (#23)

* add 3p deployment instructions

* address comments

* Update Info.plist

* Update marketing_url.txt

.gitignore

@@ -7,4 +7,20 @@ dydx/Pods/abacus/build
 dydxV4/dydxV4/_Configurations/credentials.json
 dydxV4/dydxV4/_Configurations/GoogleService-Info-Staging.plist
 dydxV4/dydxV4/_Configurations/GoogleService-Info.plist
-scripts/secrets
+scripts/secrets
+
+# fastlane specific
+**/fastlane/report.xml
+
+# deliver temporary files
+**/fastlane/Preview.html
+
+# scan temporary files
+**/fastlane/test_output
+
+*.p12
+*.certSigningRequest
+*.cer
+*.mobileprovision
+*.ipa
+*.dSYM.*

README.md

@@ -26,7 +26,7 @@ Other dependencies are specified by the Cocoapods and Swift Package Manager conf
 
 # API Keys & Secrets
 Unzip the `secrets.zip` from the `iOS Secrets` vault in the dYdX 1Password account. Ask a team member for access.
-Add the `secrets/` folder to the native-ios-v4/scripts folder.
+Add the `secrets/` folder to the v4-native-ios/scripts folder.
 
 > `mv {REPLACE_WITH_PATH_TO_UNZIPPED}/secrets {REPLACE_WITH_REPO}/scripts`
 
@@ -45,7 +45,7 @@ Javascript code is generated in v4-client. To update
 
 Get the desired commit from v4-client
 Copy from {v4-client}/__native__/__ios__/v4-native-client.js
-to {native-ios-v4}/dydx/dydxPresenters/_Feature/
+to {v4-native-ios}/dydx/dydxPresenters/_Feature/
 
 To generate v4-native-client.js from the v4-client repo, run
 

docs/branching_strategy.md

@@ -0,0 +1,159 @@
+# Project Branching and Hotfix Strategy Guide
+
+This document outlines the branching strategy our project adopts, accommodating regular development, releases, and hotfixes. Following this strategy ensures an organized development process and stable production code.
+
+## 1. General Branching Strategy
+
+Our branching method involves several branches serving distinct roles in the code changes' lifecycle. Here's what our branch structure looks like:
+
+### 1.1 `main` Branch
+
+- Stores official release history.
+- Every commit represents a production-ready state.
+
+### 1.2 `develop` Branch
+
+- Serves as a pre-production staging area.
+- It's where code merges before it's ready for production.
+
+### 1.3 Feature Branches
+
+- Branch off from `develop` and integrate back into it when the feature is complete.
+- Used for single feature development or improvements.
+
+### 1.4 Release Branches
+
+- Branch off from `develop` when it reaches a production-ready state.
+- These branches are long-lived and serve for creating a release history, enabling referencing or hotfixing in the future.
+
+**Workflow Summary:**
+
+1. Regular work (features and non-critical fixes) is done in feature branches.
+2. These are merged into `develop` upon completion.
+3. When `develop` is ready for production, a new `release/...` branch is created.
+4. Release branches may receive minor polishing and bug fixing.
+5. When finalized, the `release` branch merges into `main` and is tagged with a version number if commits were made in step 4. The release branch also merges back any changes into `develop`.
+
+## 2. Hotfix Strategy
+
+Hotfixes address critical production issues, requiring immediate resolution outside the regular cycle.
+
+### 2.1 Hotfix Branches
+
+- These are created from the appropriate `release/...` branch, providing a controlled area to fix the issue.
+- These are no different than a normal release branch aside from being based on a previous `release/...` branch instead of `main`
+- After testing, hotfixes merge into both `main` and `develop` to update the production version and include fixes in the upcoming releases.
+
+### Hotfix Workflow
+
+Let's say that an issue needing a hotfix was discovered in released version `1.0.1` 
+
+1. Locate the `release/1.0.1` branch.
+2. Branch off `release/1.0.1` into a new hotfix `release/1.0.2` branch.
+    ```sh
+    git checkout release/1.0.1
+    git pull
+    git checkout -b release/1.0.2
+    ```
+3. Implement and test the fix rigorously on the hotfix branch.
+4. If hotfix release version is **greater** than latest main version tag, follow workflow A. Otherwise follow workflow B.
+
+#### **Workflow A**
+1. merge the hotfix branch into `main`
+    ```sh
+    git checkout main
+    git merge release/1.0.2
+    ```
+2. Tag this new release merge commit on `main` with an updated version number.
+    ```sh
+    git tag -a v(new_version) -m "v1.0.2"
+    git push origin --tags
+    ```
+3. Merge the hotfix into `develop` to ensure it's part of future releases.
+    ```sh
+    git checkout develop
+    git merge release/1.0.2
+    ```
+
+#### **Workflow B**
+1.  Branch off `release/<LATEST>` into another hotfix `release/<LATEST_PATCH_INCREMENTED>` branch. 
+    ```sh
+    # e.g. LATEST is 2.1.1
+    git checkout release/<LATEST> 
+    git pull
+    # LATEST_PATCH_INCREMENTED would then be 2.1.2
+    git checkout -b release/<LATEST_PATCH_INCREMENTED> 
+    ```
+2. Merge the `release/1.0.2` hotfix changes into `release/<LATEST_PATCH_INCREMENTED>`
+    ```sh
+    git checkout release/<LATEST_PATCH_INCREMENTED>
+    git merge release/1.0.2
+    ```
+3. merge the `release/<LATEST_PATCH_INCREMENTED>` hotfix branch into `main`
+    ```sh
+    git checkout main
+    git merge release/<LATEST_PATCH_INCREMENTED>
+    ```
+4. Tag this new release merge commit on `main` with an updated version number.
+    ```sh
+    git tag -a v(new_version) -m "v<LATEST_PATCH_INCREMENTED>"
+    git push origin --tags
+    ```
+5. Merge the hotfix into `develop` to ensure it's part of future releases.
+    ```sh
+    git checkout develop
+    git merge release/<LATEST_PATCH_INCREMENTED>
+    ``` 
+
+
+
+## 3. Example
+The following branching history visualization depicts a project which:
+1. Released 1.0.0 based off the latest develop at the time
+2. Released 1.0.1 based off 1.0.0 for a hotfix
+3. Released 1.1.0 based off the latest develop at the time
+<img src="https://github.com/dydxprotocol/v4-chain/assets/3445394/53e12dcc-84b6-4f51-9a16-0ecb19288d64">
+
+This example can be recreated with [mermaid.live's tool](https://mermaid.live/) and the following code.
+```
+gitGraph
+    commit id:"1.0.0"
+    branch "develop"
+    commit id:"commit_a"
+    commit id:"commit_b"
+    branch release/1.0.0
+    checkout release/1.0.0
+    commit id:"commit_b (same HEAD)"
+    checkout develop
+    commit id:"commit_c"
+    merge release/1.0.0
+    commit id:"commit_d"
+    checkout main
+    merge release/1.0.0 tag:"v1.0.0"
+    checkout release/1.0.0
+    branch release/1.0.1
+    commit id:"commit_b (same HEAD) "
+    commit id:"commit_e (polish)"
+    checkout "develop"
+    merge release/1.0.1
+    checkout main
+    merge release/1.0.1 tag: "v1.0.1"
+    checkout develop
+    commit id: "commit_f"
+    commit id: "commit_g"
+    commit id: "commit_h"
+    branch release/1.1.0
+    checkout release/1.1.0
+    commit id:"commit_h (same head)"
+    checkout main
+    merge release/1.1.0 tag: "v1.1.0"
+```
+
+## 4. Release Management
+
+The presence of release branches adds an extra layer of stability, as they remain available for any future needs for referencing or hotfixing that specific release.
+
+## 5. Conclusion
+
+This branching strategy and hotfix procedure ensure a robust framework for continuous development, stable production releases, and efficient deployment of critical fixes. It emphasizes the importance of team collaboration, communication, and a structured approach to managing code lifecycles.
+

docs/forced_update.md

@@ -0,0 +1,62 @@
+# Forced Update Guide
+
+This document outlines how to force app users to update to a particular version.
+
+## 1. When to force an update
+
+When Blockchain contract changes, FE app may need to be updated to be compatible. While web apps can be updated in sync with the contracts, native app users may not always update to the latest version.
+</br>
+</br>
+Forced update is a mechanism to make sure the native app is compatible with the contracts, and Indexer endpoints.
+
+## 2. Forced update strategy
+
+Remote configuration is used to inform the app the minimum build number required.
+
+### 2.1 Build number
+
+Each app deployment has a build number, which is automatically incremented at build time. When the remote configuration contains a higher build number than the running app, app shows an UI to force the user to update the app.
+
+### 2.2 Update URL
+
+An URL is provided in the remote configuration. This URL should lead to the App Store to either 
+
+#### 2.2.1
+
+Update the existing app
+
+#### 2.2.2
+
+Download a different app. This is a mechanism to release completely new app and prompt users of older app to migrate to the new app.
+
+## 3. Remote Configuration
+
+The remote configuration resides inside the Environment payload in the web app deployment, which should reside in **\public\configs\env.json**
+
+Having the endpoint to the deployed web app is a necessary step to configure the native app deployment.
+
+Different environments may have different app requirements. This enables the native apps to be deployed and tested with testnets before production network is deployed.
+
+## 4. Sample Payload
+
+In each environment, there is an optional **apps** payload.
+
+```
+"apps": {
+   "ios": {
+      "minimalVersion": "1.0",
+      "build":40000,
+      "url": "https://apps.apple.com/app/dydx/id1234567890"
+   }
+ }
+ ```
+
+
+**ios** and **android** is used to identify the requirments for iOS or Android apps.
+
+**minimalVersion** used by the app to display required version. It is used for displaying only. 
+
+**build** is the minimum build number to be compatible with the environment. 
+
+**url** is the URL to the app on the App Store or Google Play Store.
+

dydxV4/dydxV4.xcodeproj/project.pbxproj

@@ -2539,7 +2539,7 @@
 					"$(inherited)",
 					"@executable_path/Frameworks",
 				);
-				MARKETING_VERSION = 0.1;
+				MARKETING_VERSION = 0.1.0;
 				PRODUCT_BUNDLE_IDENTIFIER = exchangeV4.dydx.trading;
 				PRODUCT_NAME = "$(TARGET_NAME)";
 				SWIFT_ACTIVE_COMPILATION_CONDITIONS = "$(inherited) _iOS";
@@ -2563,7 +2563,7 @@
 					"$(inherited)",
 					"@executable_path/Frameworks",
 				);
-				MARKETING_VERSION = 0.1;
+				MARKETING_VERSION = 0.1.0;
 				PRODUCT_BUNDLE_IDENTIFIER = exchangeV4.dydx.trading;
 				PRODUCT_NAME = "$(TARGET_NAME)";
 				PROVISIONING_PROFILE_SPECIFIER = "";
@@ -2586,6 +2586,7 @@
 					"@executable_path/Frameworks",
 					"@loader_path/Frameworks",
 				);
+				MARKETING_VERSION = 0.1.0;
 				PRODUCT_BUNDLE_IDENTIFIER = www.craziapps.dydxTests;
 				PRODUCT_NAME = "$(TARGET_NAME)";
 				TARGETED_DEVICE_FAMILY = "1,2";
@@ -2606,6 +2607,7 @@
 					"@executable_path/Frameworks",
 					"@loader_path/Frameworks",
 				);
+				MARKETING_VERSION = 0.1.0;
 				PRODUCT_BUNDLE_IDENTIFIER = www.craziapps.dydxTests;
 				PRODUCT_NAME = "$(TARGET_NAME)";
 				TARGETED_DEVICE_FAMILY = "1,2";