Docs(mobile): add release procedure & improve code guidelines

apps/mobile/CONTRIBUTING.md → apps/mobile/docs/code-style.md

@@ -1,8 +1,8 @@
-# React Native Code Guidelines
+# Code style guidelines
 
-## Code Structure
+## Code structure
 
-### General Components
+### General components
 
 - Components that are used across multiple features should reside in the `src/components/` folder.
 - Each component should have its own folder, structured as follows:
@@ -13,7 +13,8 @@
   - Alert.stories.tsx
   - index.tsx
   ```
-- The main component implementation should be in a named file (e.g., `Alert.tsx`), and `index.tsx` should only be used for exporting the component.
+- The main component implementation should be in a named file (e.g., `Alert.tsx`), and `index.tsx` should only be used
+  for exporting the component.
 - **Reason**: Using `index.tsx` allows for cleaner imports, e.g.,
   ```
   import { Alert } from 'src/components/Alert';
@@ -23,16 +24,16 @@
   import { Alert } from 'src/components/Alert/Alert';
   ```
 
-### Exporting Components
+### Exporting components
 
 - **Always prefer named exports over default exports.**
   - Named exports make it easier to refactor and identify exports in a codebase.
 
-### Features and Screens
+### Features and screens
 
 - Feature-specific components and screens should be implemented inside the `src/features/` folder.
 
-#### Example: Feature File Structure
+#### Example: feature file structure
 
 For a feature called **Assets**, the file structure might look like this:
 
@@ -44,9 +45,10 @@ For a feature called **Assets**, the file structure might look like this:
 
 - `index.tsx` should only export the **Assets** component/container.
 
-#### Subcomponents for Features
+#### Subcomponents for features
 
-- If a feature depends on multiple subcomponents unique to that feature, place them in a `components` subfolder. For example:
+- If a feature depends on multiple subcomponents unique to that feature, place them in a `components` subfolder. For
+  example:
 
 ```
 // src/features/Assets/components/AssetHeader
@@ -55,7 +57,7 @@ For a feature called **Assets**, the file structure might look like this:
 - index.tsx
 ```
 
-### Presentation vs. Container Components
+### Presentation vs. container components
 
 - **Presentation Components**:
 
@@ -67,3 +69,30 @@ For a feature called **Assets**, the file structure might look like this:
 - **Container Components**:
   - Handle business logic (e.g., state management, API calls, etc.).
   - Pass necessary data and callbacks to the corresponding Presentation component.
+
+### Commit message guidelines
+
+We follow the Semantic [https://www.conventionalcommits.org/en/v1.0.0/](Commit Messages convention).
+
+#### Format
+
+Each commit message should consist of a header, an optional body, and an optional footer. The header has a specific
+format that includes a type, an optional scope, and a subject:
+
+```
+<type>(<scope>): <subject>
+```
+
+**Types**
+
+- **feat**: A new feature
+- **fix**: A bug fix
+- **docs**: Documentation only changes
+- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+- **refactor**: A code change that neither fixes a bug nor adds a feature
+- **perf**: A code change that improves performance
+- **test**: Adding missing or correcting existing tests
+- **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
+- **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
+- **chore**: Other changes that don't modify src or test files
+- **revert**: Reverts a previous commit

apps/mobile/docs/release-procedure.md

@@ -0,0 +1,15 @@
+# Releasing to Production
+
+The code is being actively developed on the `dev` branch. Pull requests are made against this branch.
+
+When we want to make a release, we create a new branch from `dev` called `mobile-release/vX.Y.Z` where `X.Y.Z` is the
+version number of the release.
+
+This will trigger a new build on the CI/CD pipeline, which will build the app and submit it to the internal distribution
+lanes in App Store and Google Play Store.
+
+The release has to be tested by QA and once approved can be promoted to the production lane.
+
+## Triggering Maestro E2E tests
+
+On the release PR add the github label `eas-build-ios:build-and-maestro-test` to trigger the e2e tests in Expo CI.