branches: Update files to refer to main instead of develop

.devcontainer/README.md

@@ -24,7 +24,7 @@ In order to build InfiniTime we need to run the initial submodule init and CMake
 
 #### Manually
 
-You can use the VS Code terminal to run the CMake commands as outlined in the [build instructions](blob/develop/doc/buildAndProgram.md)
+You can use the VS Code terminal to run the CMake commands as outlined in the [build instructions](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/doc/buildAndProgram.md)
 
 #### Script
 

.github/ISSUE_TEMPLATE/bug-report.yaml

@@ -41,10 +41,10 @@ body:
     attributes:
       label: Version
       description: |
-        What [version of the firmware](https://github.com/JF002/InfiniTime/blob/develop/doc/gettingStarted/gettingStarted-1.0.md#how-to-check-the-version-of-infinitime-and-the-bootloader) are you running?
+        What [version of the firmware](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/doc/gettingStarted/updating-software.md#checking-the-version-of-infinitime) are you running?
-        If you are running an older version, please consider [updating to the latest firmware](https://github.com/JF002/InfiniTime/blob/develop/doc/gettingStarted/gettingStarted-1.0.md#how-to-update-your-pinetime).
+        If you are running an older version, please consider [updating to the latest firmware](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/doc/gettingStarted/updating-software.md#updating-with-companion-apps).
         If you are running directly from git, specify the branch or the commit hash directly.
-      placeholder: "Ex. v1.6.0 or develop or fc922b60"
+      placeholder: "Ex. v1.11.0 or main or fc922b60"
     validations:
       required: true
   - type: input

.github/ISSUE_TEMPLATE/issue-report.yaml

@@ -23,9 +23,9 @@ body:
   attributes:
     label: Version
     description: |
-      What [version of the firmware](https://github.com/JF002/InfiniTime/blob/develop/doc/gettingStarted/gettingStarted-1.0.md#how-to-check-the-version-of-infinitime-and-the-bootloader) are you running?
+      What [version of the firmware](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/doc/gettingStarted/updating-software.md#checking-the-version-of-infinitime) are you running?
-      If you are running an older version, please consider [updating to the latest firmware](https://github.com/JF002/InfiniTime/blob/develop/doc/gettingStarted/gettingStarted-1.0.md#how-to-update-your-pinetime).
+      If you are running an older version, please consider [updating to the latest firmware](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/doc/gettingStarted/updating-software.md#updating-with-companion-apps).
       If you are running directly from git, specify the branch or the commit hash directly.
-    placeholder: Ex. v1.6.0 or develop or fc922b60
+    placeholder: Ex. v1.11.0 or main or fc922b60
   validations:
     required: false

.github/workflows/docker.yml

@@ -2,11 +2,11 @@ name: Build and push Docker image
 
 on:
   push:
-    branches: [ develop ]
+    branches: [ main ]
     paths:
       - 'docker/**'
   pull_request:
-    branches: [ develop ]
+    branches: [ main ]
     paths:
       - 'docker/**'
   # Allows you to run this workflow manually from the Actions tab

.github/workflows/format.yml

@@ -2,7 +2,7 @@ name: Code formatting
 
 on:
   pull_request:
-    branches: [ develop ]
+    branches: [ main ]
     paths:
       - '**.cpp'
       - '**.h'

.github/workflows/main.yml

@@ -3,12 +3,12 @@ name: CI
 # Run this workflow whenever the build may be affected
 on:
   push:
-    branches: [ master, develop ]
+    branches: [ main ]
     paths-ignore:
       - 'doc/**'
       - '**.md'
   pull_request:
-    branches: [ develop ]
+    branches: [ main ]
     paths-ignore:
       - 'doc/**'
       - '**.md'

.github/workflows/pr-comment.yml

@@ -5,7 +5,7 @@ name: PR comment
 
 on:
   pull_request_target:
-    branches: [ develop ]
+    branches: [ main ]
     paths-ignore:
       - 'doc/**'
       - '**.md'

CONTRIBUTING.md

@@ -22,7 +22,7 @@ The workflow is based on [GitHub flow](https://docs.github.com/en/get-started/qu
 
 To create a pull request,
 you need a [fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks) of the repo.
-Create a new [branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches) from develop,
+Create a new [branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches) from main,
 make changes in this branch,
 [commit](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/about-commits) them,
 and create a [pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request).

doc/ExternalResources.md

@@ -6,7 +6,7 @@ This page describes how the resources are integrated in InfiniTime from a develo
 
 ## Resources generation
 
-Resources are generated at build time via the [CMake target `Generate  Resources`](https://github.com/InfiniTimeOrg/InfiniTime/blob/develop/src/resources/CMakeLists.txt#L19). 
+Resources are generated at build time via the [CMake target `Generate  Resources`](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/src/resources/CMakeLists.txt#L19). 
 It runs 3 Python scripts that respectively convert the fonts to binary format, convert the images to binary format and package everything in a .zip file.
 
 The resulting file `infinitime-resources-x.y.z.zip` contains the images and fonts converted in binary `.bin` files and a JSON file `resources.json`. 

doc/MemoryAnalysis.md

@@ -104,7 +104,7 @@ In Infinitime 1.1, the biggest buffers are the buffers allocated for LVGL (14KB)
 
 ### Stack
 
-The stack will be used for everything except tasks, which have their own stack allocated by FreeRTOS. The stack is 8192B and is allocated in the [linker script](https://github.com/InfiniTimeOrg/InfiniTime/blob/develop/nrf_common.ld#L148).
+The stack will be used for everything except tasks, which have their own stack allocated by FreeRTOS. The stack is 8192B and is allocated in the [linker script](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/nrf_common.ld#L148).
 An easy way to monitor its usage is by filling the section with a known pattern at boot time, then use the firmware and dump the memory. You can then check the maximum stack usage by checking the address from the beginning of the stack that were overwritten.
 
 #### Fill the stack section by a known pattern:
@@ -216,7 +216,7 @@ According to my experimentations, we don't use the stack that much, and 8192 byt
 
 ### Heap
 
-The heap is declared in the [linker script](https://github.com/InfiniTimeOrg/InfiniTime/blob/develop/nrf_common.ld#L136) and its current size is 8192 bytes. The heap is used for dynamic memory allocation(`malloc()`, `new`...).
+The heap is declared in the [linker script](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/nrf_common.ld#L136) and its current size is 8192 bytes. The heap is used for dynamic memory allocation(`malloc()`, `new`...).
 
 Heap monitoring is not easy, but it seems that we can use the following code to know the current usage of the heap:
 

doc/branches.md

@@ -1,14 +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/).
+The project has 1 main branch, aptly called **main**.
+This branch contains the latest development that will be tagged for the next release once it's considered stable.
 
-The project is based on 2 main branches:
+New features should be implemented in **feature branches** created from **main**.
+When the feature is ready, a pull request is created and it'll be merged into **main** when it is successfully reviewed and accepted.
 
-- **master** : this branch is always ready to be deployed. It means that at any time, we should be able to build the branch and release a new version of the application.
+To release a new version of the application, when main is considered stable, a tag is created on the version bump commit in **main** and the release is generated (a tag is applied to git, the release note is finalized, binaries are built,...).
-- **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 successfully reviewed and accepted.
+We also supports the creation of **hotfix** branches when a bug is discovered in a released version. The **hotfix** branch is created from the latest tag and will be used only to implement a fix to this bug.
-
+Multiple hotfix branches can be created for the same release if multiple bugs are discovered.
-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 multiple bugs are discovered.

doc/buildAndProgram.md

@@ -48,7 +48,7 @@ CMake configures the project according to variables you specify the command line
 #### (\*) Note about **CMAKE_BUILD_TYPE**
 By default, this variable is set to *Release*. It compiles the code with size and speed optimizations. We use this value for all the binaries we publish when we [release](https://github.com/InfiniTimeOrg/InfiniTime/releases) new versions of InfiniTime.
 
-The *Debug* mode disables all optimizations, which makes the code easier to debug. However, the binary size will likely be too big to fit in the internal flash memory. If you want to build and debug a *Debug* binary, you'll need to disable some parts of the code. For example, the icons for the **Navigation** app use a lot of memory space. You can comment the content of `m_iconMap` in the [Navigation](https://github.com/InfiniTimeOrg/InfiniTime/blob/develop/src/displayapp/screens/Navigation.h#L148) application to free some memory.
+The *Debug* mode disables all optimizations, which makes the code easier to debug. However, the binary size will likely be too big to fit in the internal flash memory. If you want to build and debug a *Debug* binary, you'll need to disable some parts of the code. For example, the icons for the **Navigation** app use a lot of memory space. You can comment the content of `m_iconMap` in the [Navigation](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/src/displayapp/screens/Navigation.h#L148) application to free some memory.
 
 #### (\*\*) Note about **BUILD_DFU**
 DFU files are the files you'll need to install your build of InfiniTime using OTA (over-the-air) mechanism. To generate the DFU file, the Python tool [adafruit-nrfutil](https://github.com/adafruit/Adafruit_nRF52_nrfutil) is needed on your system. Check that this tool is properly installed before enabling this option.

doc/versioning.md

@@ -3,5 +3,5 @@
 The versioning of this project is based on [Semantic versioning](https://semver.org/):
 
 - The **patch** is incremented when a bug is fixed on a **released** version (most of the time using a **hotfix** branch).
-- The **minor** is incremented when a new version with new features is released. It corresponds to a merge of **develop** into **master**.
+- The **minor** is incremented when a new version with new features is released. It corresponds to a tag of a commit in **main**.
 - 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.