Merge branch 'develop' of git.proxmox3:JF/PineTime into develop

# Conflicts:
#	README.md

README.md

@@ -26,13 +26,13 @@ As of now, here is the list of achievements of this project:
  - Rich user interface via display, touch panel and push button
  - Time synchronization via BLE
  - Notification via BLE
- - Multiple 'apps': 
+ - Multiple 'apps' : 
-    * Clock (displays the date, time, battery level, ble connection status, heart rate and step count)
+    * Clock (displays the date, time, battery level, BLE connection status, heart rate and step count)
     * Heart rate
     * Motion
-    * System info (displays various info: BLE MAC, build date/time, uptime, version, ...)
+    * System info (displays various info : BLE MAC adress, build date/time, uptime, version, ...)
     * Brightness (allows the user to configure the brightness of the display)
- - Supported by 2 companion apps (developments ongoing):
+ - Supported by 2 companion apps (development is ongoing):
     * [Gadgetbridge](https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/pinetime-jf) (on Android)
     * [Amazfish](https://openrepos.net/content/piggz/amazfish) (on SailfishOS)
  - **[Experimental]** OTA (Over-the-air) update via BLE
@@ -41,13 +41,18 @@ As of now, here is the list of achievements of this project:
 ## Documentation
 
 ### Build, flash and debug
+ - [Project branches](doc/branches.md)
+ - [Versioning](doc/versioning.md)
  - [Files included in the release notes](doc/filesInReleaseNotes.md)
  - [Build the project](doc/buildAndProgram.md)
  - [Bootloader, OTA and DFU](./bootloader/README.md)
  - [Stub using NRF52-DK](./doc/PinetimeStubWithNrf52DK.md)
  - Logging with JLink RTT.
  - Using files from the releases
- 
+
+## Contribute
+ - [How to contribute ?](doc/contribute.md)
+
 ### API
  - [BLE implementation and API](./doc/ble.md)
  
@@ -74,7 +79,7 @@ Here a quick list out of my head of things to do for this project:
  - Measure power consumption and improve battery life
  - Improve documentation, take better pictures and video than mine
  - Improve the UI
- - Create companion app for multiple OSes (Linux, Android, IoS) and platforms (desktop, ARM, mobile). Do not forget the other devices from Pine64 like [the Pinephone](https://www.pine64.org/pinephone/) and the [Pinebook Pro](https://www.pine64.org/pinebook-pro/). 
+ - Create companion app for multiple OSes (Linux, Android, iOS) and platforms (desktop, ARM, mobile). Do not forget the other devices from Pine64 like [the Pinephone](https://www.pine64.org/pinephone/) and the [Pinebook Pro](https://www.pine64.org/pinebook-pro/). 
  - Design a simple CI (preferably self-hosted and easy to reproduce).
  
 Do not hesitate to clone/fork the code, hack it and create pull-requests. I'll do my best to review and merge them :)
@@ -85,7 +90,7 @@ I’m not working alone on this project. First, many people create PR for this p
 Here are some people I would like to highlight:
 
  - [Atc1441](https://github.com/atc1441/) : He works on an Arduino based firmware for the Pinetime and many other smartwatches based on similar hardware. He was of great help when I was implementing support for the BMA421 motion sensor and I²C driver.
- - [Koen](https://github.com/bosmoment) : He’s working on a firmware based on RiotOS. He integrated similar libs than me : NimBLE, LittleVGL,… His help was invaluable too!
+ - [Koen](https://github.com/bosmoment) : He’s working on a firmware based on RiotOS. He integrated similar libs as me : NimBLE, LittleVGL,… His help was invaluable too!
  - [Lup Yuen Lee](https://github.com/lupyuen) : He is everywhere: he works on a Rust firmware, builds a MCUBoot based bootloader for the Pinetime, designs a Flutter based companion app for smartphones and writes a lot of articles about the Pinetime!
 
 *If you feel like you should appear on this list, just get in touch with me or submit a PR :)*

doc/branches.md

@@ -0,0 +1,12 @@
+# Branches
+The branching model of this project is based on the workflow named [Git flow](https://nvie.com/posts/a-successful-git-branching-model/).
+
+It is based on 2 main branches:
+ - **master** : this branch is always ready to be reployed. It means that at any time, we should be able to build the branch and release a new version of the application.
+ - **develop** : this branch contains the latest development that will be integrated in the next release once it's considered as stable.
+
+New features should be implemented in **feature branches** created from **develop**. When the feature is ready, a pull-request is created and it'll be merge into **develop** when it is succesfully reviewed and accepted.
+
+To release a new version of the application, when develop is considered stable, a **release** branch is created from **develop**. This can be considered as a *release candidate* branch. When everything is OK, this release branch is merged into **master** and the release is generated (a tag is applied to git, the release note is finalized, binaries are built,...) from **master**.
+
+Git flow also supports the creation of **hotfix** branches when a bug is discovered in a released version. The **hotfix** branch is created from **master** and will be used only to implement a fix to this bug. Multiple hotfix branches can be created for the same release if more than one bugs are discovered.

doc/contribute.md

@@ -0,0 +1,24 @@
+# How to contribute?
+## Report bugs
+You use your Pinetime and find a bug in the firmware? [Create an issue on Github](https://github.com/JF002/Pinetime/issues) explaining the bug, how to reproduce it, the version of the firmware you use...
+## Write and improve documentation
+Documentation might be incomplete, or not clear enough, and it is always possible to improve it with better wording, pictures, photo, video,... 
+
+As the documentation is part of the source code, you can submit your improvements to the documentation by submitting a pull request (see below).
+## Fix bugs, add functionalities and improve the code
+You want to fix a bug, add a cool new functionality or improve the code? See *How to submit a pull request below*.
+## Spread the word
+Pinetime is a cool open source project that deserves to be know. Talk about it around you, on social networks, on your blog,... and let people know that we are working on an open-source firmware for a smartwatch!
+
+# How to submit a pull request ?
+Your contribution is more than welcome! 
+
+If you want to fix a bug, add a functionality or improve the code, you'll first need to create a branch from the **develop** branch (see [this page about the branching model](./branches.md)). This branch is called a feature branch, and you should choose a name that explains what you are working on (ex: "add-doc-about-contributions"). In this branch, try to focus on only one topic, bug or feature. For example, if you created this branch to work on the UI of a specific application, do not commit modifications about the SPI driver. If you want to work on multiple topics, create one branch per topic.
+
+When your feature branch is ready, make sure it actually works and do not forget to write documentation about it if necessary.
+
+Then, you can submit a pull-request for review. Try to describe your pull request as much as possible: what did you do in this branch, how does it work, how is it designed, are there any limitations,... This will help the contributors to understand and review your code easily.
+
+Other contributors can post comments about the pull request, maybe ask for more info or adjustements in the code.
+
+Once the pull request is reviewed an accepted, it'll be merge in **develop** and will be released in the next release version of the firmware.

doc/versioning.md

@@ -0,0 +1,6 @@
+# Versioning
+The versioning of this project is based on [Semantic versionning](https://semver.org/) :
+
+ - The **patch** is incremented when we fix a bug on a **released** version (most of the time using a **hotfix** branch).
+ - The **minor** is incremented when we release a new version with new features. It corresponds to a merge of **develop** into **master**.
+ - The **major** should be incremented when a breaking change is made to the application. We still have to define what is a breaking change in the context of this project. For now, I suggest that it stays **0** until we have a fully functionning firmware suited for the final user.