Dockery/Trilium
1
0
Fork 0
mirror of https://github.com/zadam/trilium.git synced 2025-12-19 22:59:53 +01:00
Code Issues Packages Projects Releases Activity

docs(dev): releasing a new version

Browse Source
This commit is contained in:
Elian Doran
2025-11-04 09:21:44 +02:00
parent 59a2ef7527
commit db644f20ed
4 changed files with 57 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/Developer Guide/Developer Guide/Building/Documentation.md vendored
View File

@@ -1,4 +1,8 @@
# Documentation
## Editing the documentation
To edit the documentation run `pnpm edit-docs:edit-docs`. This will spin up a custom Trilium desktop instance which automatically imports the documentation into memory. Any changes will update in the background the files which can then be committed.
## Automation
The documentation is built via `apps/build-docs`:

19
docs/Developer Guide/Developer Guide/Building/Releasing a new version.md vendored Normal file
View File

@@ -0,0 +1,19 @@
# Releasing a new version
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.
The process is as follows:
1. Edit the <a class="reference-link" href="Documentation.md">Documentation</a> to add a corresponding entry in the _Release notes_ section.
2. In the root `package.json`, set `version` to the new version to be released.
3. Run `chore:update-version` to automatically update the version of the rest of the `package.json` files.
4. Run `pnpm i` to update the package lock as well.
5. Commit the changes to the `package.json` files and the `package-lock.json`. The commit message is usually `chore(release): prepare for v1.2.3`.
6. Tag the newly created commit: `git tag v1.2.3`
7. Push the commit and the newly created tag: `git push; git push --tags`.
8. Wait for the CI to finish.
9. When the release is automatically created in GitHub, download it to make sure it works OK.

22
docs/Developer Guide/Developer Guide/Old documentation/Releasing a version.md vendored
View File

@@ -1,22 +0,0 @@
# Releasing a version
On NixOS:
```
nix-shell -p dpkg fakeroot jq nodejs_20
```
Then simply run from project root:
```
./bin/release.sh 1.2.3
```
where `1.2.3` is the desired release version.
If a version ends with `-beta`, it will automatically be marked as pre-release in GitHub.
This will automatically generate a release in GitHub if everything goes according to plan.
Note that the Windows installer is not automatically uploaded yet, it has to be taken from the [main workflow of the CI from the `develop` branch](../Architecture/CI/Main.md).
Make sure to check test the artifacts of the release.