Update README (#1367)

hpdang · hpdang · web-flow · commit f36ef45b60b5 · 2025-07-15T09:49:03.000+02:00
Co-authored-by: hpdang &lt;“[dhppat@gmail.com]”&gt;
diff --git a/README.md b/README.md
@@ -1,7 +1,7 @@
 <img height="200px" src="./docs/images/app_icon.png" align="right" />
 
 # Badge Magic
-[![Join the chat at https://gitter.im/fossasia/badge-magic](https://badges.gitter.im/fossasia/badge-magic.svg)](https://gitter.im/fossasia/badge-magic?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) 
+[![Join the chat at https://gitter.im/fossasia/badge-magic](https://badges.gitter.im/fossasia/badge-magic.svg)](https://gitter.im/fossasia/badge-magic?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
 ![Github](https://img.shields.io/github/license/fossasia/badgemagic-app?logo=github)
 
 **Python Library to program via desktop https://github.com/fossasia/led-name-badge-ls32**
@@ -29,7 +29,7 @@ The Badge Magic Android app lets you create moving text and draw clipart for LED
 * **Bluetooth**: For sending org.fossasia.badgemagic.data to the badge.
 * **Storage**: For storing and saving badges.
 
-Up to Android version 11 
+Up to Android version 11
 * **GPS Location**: This has been the standard set by Android for use with Bluetooth Low Energy (BLE) devices. For more information, please read the notes on [Android website](https://source.android.com/devices/bluetooth/ble).
 
 ## Communication
@@ -61,21 +61,24 @@ There are a number of devices with Bluetooth on the market. As far as we can tel
 
 ## Reverse-Engineering Bluetooth LE Devices
 
-Security in Bluetooth LE devices is optional, and many cheap products you can find on the market are not secured at all. This applies to our Bluetooth LED Badge. While this could lead to some privacy issues, this can also be a source of fun, especially when you want to use an LED Badge in a different way. It also makes it easy for us to get started with the development of a Free and Open Source Android app. 
+Security in Bluetooth LE devices is optional, and many cheap products you can find on the market are not secured at all. This applies to our Bluetooth LED Badge. While this could lead to some privacy issues, this can also be a source of fun, especially when you want to use an LED Badge in a different way. It also makes it easy for us to get started with the development of a Free and Open Source Android app.
 
-As we understand how the Bluetooth LED badge works, converting a text to multiple byte arrays, we can send using the Bluetooth LE APIs. An indepth blog post about reverse-engineering the Bluetooth community [is here](http://nilhcem.com/iot/reverse-engineering-bluetooth-led-name-badge). 
+As we understand how the Bluetooth LED badge works, converting a text to multiple byte arrays, we can send using the Bluetooth LE APIs. An indepth blog post about reverse-engineering the Bluetooth community [is here](http://nilhcem.com/iot/reverse-engineering-bluetooth-led-name-badge).
 
-The implementation in the Android app consists of manipulating bits. That may be tricky. A single bit error and nothing will work, plus it will be hard to debug. For those reasons, and since the specs are perfectly clear the reverse engineer Gautier Mechling strongly recommends to start writing unit tests before the code implementation. 
+The implementation in the Android app consists of manipulating bits. That may be tricky. A single bit error and nothing will work, plus it will be hard to debug. For those reasons, and since the specs are perfectly clear the reverse engineer Gautier Mechling strongly recommends to start writing unit tests before the code implementation.
 
 ## Branch Policy
 
 We have the following branches
 
- * **development** All development goes on in this branch. If you're making a contribution, you are supposed to make a pull request to _development_. PRs to development branch must pass a build check on CI/CD.
- * **apk** This branch contains many apk files, that are automatically generated on the merged pull request a) debug apk b) release apk
+ * **development**: All development goes on in this branch. If you're making a contribution, you are supposed to make a pull request to _development_. PRs to development branch must pass a build check on CI/CD.
+ * **apk**: This branch contains many apk files, that are automatically generated on the merged pull request a) debug apk b) release apk
     - There are multiple files in the apk branch of the project, this branch consists of all the APK files and other files that are relevant when an APK is generated.
     - Once a pull request is merged, the previous APK branch is deleted and a new APK branch is created.
     - If a PR is merged in development branch then the new APKs for the development branch are generated whereas the APKs corresponding to the master branch are not regenerated and simply the previously generated files are added.
+* **version**: This branch stores the version information for the APKs (versionName and versionCode). This is used in our workflows for automatic versioning wherein the next version information is automatically fetched from this branch and used for building APKs.
+* **fastlane***: These branches contain information and metadata used by fastlane to automate deployment.
+* **pr-screenshots**: This branch stores screenshots for every open pull request, which are shown in comments in every pull request.
 
 ## Contributions Best Practices
 
@@ -89,6 +92,27 @@ Please read FOSSASIA's [Best Practices](https://blog.fossasia.org/open-source-de
 * Before you join development, please set up the project on your local machine, run it and go through the application completely. Press on any button you can find and see where it leads to. Explore.
 * If you would like to work on an issue, drop in a comment at the issue. If it is already assigned to someone, but there is no sign of any work being done, please free to drop in a comment and start working on it.
 
+## Release Process
+
+### Beta Release Flow
+* All merged pull requests into the development branch are automatically included in the beta version of the app.
+* The beta builds are automatically pushed to:
+  - Google Play Store (Beta Track)
+  - Apple TestFlight (iOS Beta)
+This allows contributors and testers to try out the latest features and verify stability before the app is released to all users.
+
+### Production Release Flow
+* A new GitHub release (using the "Releases" tab) is the trigger for publishing a production version.
+* When a GitHub release is created:
+  - The latest beta APK or iOS build is promoted to the production track on the respective app stores.
+  - No additional code changes are made unless specified.
+This ensures that the version tested in beta is the exact one released to the public.
+
+### Notes
+* Please ensure all features and fixes are tested and merged into development before a GitHub release is created.
+* Versioning and changelogs should be updated accordingly.
+* If any hotfixes are required post-release, they should go through the same flow (PR → beta → release).
+
 ## Dev Container usage
 
 Opening this repository in VSCode, GitHub Codespaces or another supported editor/IDE will allow the repository to be opened in a [Dev Container](https://containers.dev/).
