branches: Update files to refer to main instead of develop

This commit is contained in:
Finlay Davidson 2023-03-01 23:42:29 +01:00 committed by Riku Isokoski
parent 692a9bee5d
commit 3b084d74c3
13 changed files with 26 additions and 28 deletions

View file

@ -24,7 +24,7 @@ In order to build InfiniTime we need to run the initial submodule init and CMake
#### Manually #### 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 #### Script

View file

@ -41,10 +41,10 @@ body:
attributes: attributes:
label: Version label: Version
description: | 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. 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: validations:
required: true required: true
- type: input - type: input

View file

@ -23,9 +23,9 @@ body:
attributes: attributes:
label: Version label: Version
description: | 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. 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: validations:
required: false required: false

View file

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

View file

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

View file

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

View file

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

View file

@ -22,7 +22,7 @@ The workflow is based on [GitHub flow](https://docs.github.com/en/get-started/qu
To create a pull request, 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. 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, 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, [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). 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).

View file

@ -6,7 +6,7 @@ This page describes how the resources are integrated in InfiniTime from a develo
## Resources generation ## 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. 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`. 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`.

View file

@ -104,7 +104,7 @@ In Infinitime 1.1, the biggest buffers are the buffers allocated for LVGL (14KB)
### Stack ### 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. 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: #### 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 ### 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: Heap monitoring is not easy, but it seems that we can use the following code to know the current usage of the heap:

View file

@ -1,14 +1,12 @@
# Branches # 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.

View file

@ -48,7 +48,7 @@ CMake configures the project according to variables you specify the command line
#### (\*) Note about **CMAKE_BUILD_TYPE** #### (\*) 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. 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** #### (\*\*) 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. 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.

View file

@ -3,5 +3,5 @@
The versioning of this project is based on [Semantic versioning](https://semver.org/): 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 **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. - 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.