From 3b084d74c3b3864a4ce666dce0285aaf43a48a29 Mon Sep 17 00:00:00 2001 From: Finlay Davidson Date: Wed, 1 Mar 2023 23:42:29 +0100 Subject: [PATCH] branches: Update files to refer to main instead of develop --- .devcontainer/README.md | 2 +- .github/ISSUE_TEMPLATE/bug-report.yaml | 6 +++--- .github/ISSUE_TEMPLATE/issue-report.yaml | 6 +++--- .github/workflows/docker.yml | 4 ++-- .github/workflows/format.yml | 2 +- .github/workflows/main.yml | 4 ++-- .github/workflows/pr-comment.yml | 2 +- CONTRIBUTING.md | 2 +- doc/ExternalResources.md | 2 +- doc/MemoryAnalysis.md | 4 ++-- doc/branches.md | 16 +++++++--------- doc/buildAndProgram.md | 2 +- doc/versioning.md | 2 +- 13 files changed, 26 insertions(+), 28 deletions(-) diff --git a/.devcontainer/README.md b/.devcontainer/README.md index b243a64a..fc755ba1 100644 --- a/.devcontainer/README.md +++ b/.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 diff --git a/.github/ISSUE_TEMPLATE/bug-report.yaml b/.github/ISSUE_TEMPLATE/bug-report.yaml index 4c85742a..f032d034 100644 --- a/.github/ISSUE_TEMPLATE/bug-report.yaml +++ b/.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? - 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). + 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/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 diff --git a/.github/ISSUE_TEMPLATE/issue-report.yaml b/.github/ISSUE_TEMPLATE/issue-report.yaml index f46499aa..05cca32c 100644 --- a/.github/ISSUE_TEMPLATE/issue-report.yaml +++ b/.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? - 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). + 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/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 diff --git a/.github/workflows/docker.yml b/.github/workflows/docker.yml index 7af81515..560e4433 100644 --- a/.github/workflows/docker.yml +++ b/.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 diff --git a/.github/workflows/format.yml b/.github/workflows/format.yml index 32451a0b..71c05fa2 100644 --- a/.github/workflows/format.yml +++ b/.github/workflows/format.yml @@ -2,7 +2,7 @@ name: Code formatting on: pull_request: - branches: [ develop ] + branches: [ main ] paths: - '**.cpp' - '**.h' diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index e416a7c8..89c1b276 100644 --- a/.github/workflows/main.yml +++ b/.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' diff --git a/.github/workflows/pr-comment.yml b/.github/workflows/pr-comment.yml index 9f3d2880..15f0c02d 100644 --- a/.github/workflows/pr-comment.yml +++ b/.github/workflows/pr-comment.yml @@ -5,7 +5,7 @@ name: PR comment on: pull_request_target: - branches: [ develop ] + branches: [ main ] paths-ignore: - 'doc/**' - '**.md' diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 83614e81..e894b5bc 100644 --- a/CONTRIBUTING.md +++ b/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). diff --git a/doc/ExternalResources.md b/doc/ExternalResources.md index 85319f6f..8a67f9cf 100644 --- a/doc/ExternalResources.md +++ b/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`. diff --git a/doc/MemoryAnalysis.md b/doc/MemoryAnalysis.md index fe493ba0..86180fcc 100644 --- a/doc/MemoryAnalysis.md +++ b/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: diff --git a/doc/branches.md b/doc/branches.md index cf98684b..93b04908 100644 --- a/doc/branches.md +++ b/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. -- **develop** : this branch contains the latest development that will be integrated in the next release once it's considered as stable. +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,...). -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. - -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. +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. diff --git a/doc/buildAndProgram.md b/doc/buildAndProgram.md index 3d85dc36..7909c59c 100644 --- a/doc/buildAndProgram.md +++ b/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. diff --git a/doc/versioning.md b/doc/versioning.md index 28ca085c..850430ab 100644 --- a/doc/versioning.md +++ b/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.