docs(dev): branching strategy

This commit is contained in:
Elian Doran
2025-11-10 19:29:50 +02:00
parent 52691b9e88
commit 3b5d749d86
10 changed files with 221 additions and 160 deletions

View File

@@ -0,0 +1,30 @@
# Branching strategy
## Main branch
The main development branch is conveniently called `main`. This branch contains all the merged features and is considered semi-stable.
## Development
Every new development must be done in a separate branch (usually prefixed with `feature/`). The PR must then be reviewed.
## Reviewing
Each PR must be tested manually and reviewed by a maintainer. For PRs that are made by the maintainers themselves, an LLM review from Copilot or Gemini are also accepted.
After a PR is approved, it is merged into the `main` branch and the change log draft is updated.
## Releasing
[Releasing a new version](Building/Releasing%20a%20new%20version.md) is done straight from the `main` branch once it's deemed stable enough for production.
## Hot-fixing
After releasing a new version, it's sometimes desirable to create a hotfix in order to fix some issues with the production version without introducing many changes that might have already been merged in `main`.
To do so, the procedure is as follows:
1. A `hotfix` branch is created, from the tag of the release.
2. If fixes/features from the `main` branch are needed, they are cherry-picked directly onto the branch.
3. New fixes/features are either developed directly on the `hotfix` branch or an a PR that targets this branch, depending on the complexity.
4. A new version is released from the `hotfix` version.
5. The `hotfix` version is merged back into `main`, via a PR.

View File

@@ -4,7 +4,7 @@ Releasing is mostly handled by the CI:
* The version on GitHub is published automatically, including the description with the change log which is taken from the documentation.
* A PR is created automatically on the Winget repository to update to the new version.
Releases are usually made directly from the `main` branch.
Releases are usually made directly from the `main` branch. For hot-fixes the process is the same but with a different branch, consult the <a class="reference-link" href="../Branching%20strategy.md">Branching strategy</a> for more information.
The process is as follows:

View File

@@ -1,5 +1,5 @@
# Documentation
There are multiple types of documentation for Trilium:<img class="image-style-align-right" src="api/images/lXPC13oY8arw/Documentation_image.png" width="205" height="162">
There are multiple types of documentation for Trilium:<img class="image-style-align-right" src="api/images/E6pFkO6VwPFI/Documentation_image.png" width="205" height="162">
* The _User Guide_ represents the user-facing documentation. This documentation can be browsed by users directly from within Trilium, by pressing <kbd>F1</kbd>.
* The _Developer's Guide_ represents a set of Markdown documents that present the internals of Trilium, for developers.