mirror of
https://github.com/zadam/trilium.git
synced 2025-11-18 03:00:41 +01:00
docs(dev): branching strategy
This commit is contained in:
30
docs/Developer Guide/Developer Guide/Branching strategy.md
vendored
Normal file
30
docs/Developer Guide/Developer Guide/Branching strategy.md
vendored
Normal 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.
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user