diff options
author | nodiscc <nodiscc@gmail.com> | 2020-05-16 12:54:51 +0200 |
---|---|---|
committer | nodiscc <nodiscc@gmail.com> | 2020-09-12 14:31:45 +0200 |
commit | 91a21c272960889afd4eaa431a3d29b7785b6efc (patch) | |
tree | 26e3ba62319964c5fd48d93fdfe47813d5dc9bf5 /doc/md/Versioning-and-Branches.md | |
parent | 6128ab6a55430a2b705be31ff417c0c552a0db1f (diff) | |
download | Shaarli-91a21c272960889afd4eaa431a3d29b7785b6efc.tar.gz Shaarli-91a21c272960889afd4eaa431a3d29b7785b6efc.tar.zst Shaarli-91a21c272960889afd4eaa431a3d29b7785b6efc.zip |
**General rewording, proof-reading, deduplication, shortening, reordering, simplification, cleanup/formatting/standardization**
- standardize page names, rework documentation structure, update TOC
- use same example paths everywhere
- level 1 titles on all pages
- fix broken links
- .md suffix on all page links (works both from readthedocs and github repository views)
**Server:**
A full and concise installation guide with examples is a frequent request. The documentation should provide such a guide for basic installation needs, while explaining alternative/advanced configuration at the end. Links to reference guides and documentation should be used more frequently to avoid recommending an outdated or excessively complex configuration.
- server: move most server-related info to server-configuration.md, cleanup/shorten
- server: update list of php dependencies/libraries, link to composer.json
- server: installation: support 3 install methods (from release zip, from sources, using docker)
- server: installation: use rsync instead of mv as mv results will change depending of taget directory already existing or not
- server: add example/basic usage of certbot
- server, upgrade, installation: update file permissions setup, use sudo for upgrade operations in webserver document root
- server: apache: add comments to configuration, fix and factorize file permissions setup, set cache-control header, deny access to dotfiles, add missing apache config steps, add http->https redirect example
- server: nginx: refactor nginx configuration, add comments, DO log access to denied/protected files
- server: add links to MDN for x-forwarded-* http headers explanation, cleanup/clarify robots.txt and crawlers section
- server: bump file upload size limit to 100MB we have reports of bookmark exports weighing +40MB - i have a 13MB one here
- server: simplify phpinfo documentation
- server: move backup and restore information to dedicated page
- docker: move all docker docs to Docker.md, simplify/ docker setup, add docker-compose.yml example, replace docker-101 with docker cheatsheet
- troubleshooting: move all troubleshooting documentation to troubleshooting.md
**Usage:**
- index: add getting started section on index page
- features/usage: move all usage-related documentation to usage.md, add links from the main feature list to corresponding usage docs, clarify/reword features list
- shaarli configuration: add note about configuring from web interface
**Removed:**
- remove obsolete/orphan images
- remove obsolete shaarchiver example
- remove outdated "decode datastore content" snippet
**Development:**
- development: move development-related docs (static analysis, CI, unit tests, 3rd party libs, link structure/directory, guidelines, security....) to dev/ directory
- development: Merge several pages to development.md
- **Breaking change?:** remove mentions of 'stable' branch, switch to new branch/release model (master=latest commit, release=latest tag)
- **Breaking change?:** refer to base sharing unit as "Shaare" everywhere (TODO: reflect changes in the code?) doc: update featues list/link to usage.md for details
- development: directory structure: add note about required file permissions
- .travis-ci.yml: add comments
- .htaccess: add comment
Diffstat (limited to 'doc/md/Versioning-and-Branches.md')
-rw-r--r-- | doc/md/Versioning-and-Branches.md | 75 |
1 files changed, 0 insertions, 75 deletions
diff --git a/doc/md/Versioning-and-Branches.md b/doc/md/Versioning-and-Branches.md deleted file mode 100644 index 7097ca0a..00000000 --- a/doc/md/Versioning-and-Branches.md +++ /dev/null | |||
@@ -1,75 +0,0 @@ | |||
1 | **WORK IN PROGRESS** | ||
2 | |||
3 | It's important to understand how Shaarli branches work, especially if you're maintaining a 3rd party tools for Shaarli (theme, plugin, etc.), to be sure stay compatible. | ||
4 | |||
5 | ## `master` branch | ||
6 | |||
7 | The `master` branch is the development branch. Any new change MUST go through this branch using Pull Requests. | ||
8 | |||
9 | Remarks: | ||
10 | |||
11 | - This branch shouldn't be used for production as it isn't necessary stable. | ||
12 | - 3rd party aren't required to be compatible with the latest changes. | ||
13 | - Official plugins, themes and libraries (contained within Shaarli organization repos) must be compatible with the master branch. | ||
14 | - The version in this branch is always `dev`. | ||
15 | |||
16 | ## `v0.x` branch | ||
17 | |||
18 | This `v0.x` branch, points to the latest `v0.x.y` release. | ||
19 | |||
20 | Explanation: | ||
21 | |||
22 | When a new version is released, it might contains a major bug which isn't detected right away. For example, a new PHP version is released, containing backward compatibility issue which doesn't work with Shaarli. | ||
23 | |||
24 | In this case, the issue is fixed in the `master` branch, and the fix is backported the to the `v0.x` branch. Then a new release is made from the `v0.x` branch. | ||
25 | |||
26 | This workflow allow us to fix any major bug detected, without having to release bleeding edge feature too soon. | ||
27 | |||
28 | ## `latest` branch | ||
29 | |||
30 | This branch point the latest release. It recommended to use it to get the latest tested changes. | ||
31 | |||
32 | ## `stable` branch | ||
33 | |||
34 | The `stable` branch doesn't contain any major bug, and is one major digit version behind the latest release. | ||
35 | |||
36 | For example, the current latest release is `v0.8.3`, the stable branch is an alias to the latest `v0.7.x` release. When the `v0.9.0` version will be released, the stable will move to the latest `v0.8.x` release. | ||
37 | |||
38 | Remarks: | ||
39 | |||
40 | - Shaarli release pace isn't fast, and the stable branch might be a few months behind the latest release. | ||
41 | |||
42 | ## Releases | ||
43 | |||
44 | Releases are always made from the latest `v0.x` branch. | ||
45 | |||
46 | Note that for every release, we manually generate a tarball which contains all Shaarli dependencies, making Shaarli's installation only one step. | ||
47 | |||
48 | ## Advices on 3rd party git repos workflow | ||
49 | |||
50 | ### Versioning | ||
51 | |||
52 | Any time a new Shaarli release is published, you should publish a new release of your repo if the changes affected you since the latest release (take a look at the [changelog](https://github.com/shaarli/Shaarli/releases) (*Draft* means not released yet) and the commit log (like [`tpl` folder](https://github.com/shaarli/Shaarli/commits/master/tpl/default) for themes)). You can either: | ||
53 | |||
54 | - use the Shaarli version number, with your repo version. For example, if Shaarli `v0.8.3` is released, publish a `v0.8.3-1` release, where `v0.8.3` states Shaarli compatibility and `-1` is your own version digit for the current Shaarli version. | ||
55 | - use your own versioning scheme, and state Shaarli compatibility in the release description. | ||
56 | |||
57 | Using this, any user will be able to pick the release matching his own Shaarli version. | ||
58 | |||
59 | ### Major bugfix backport releases | ||
60 | |||
61 | To be able to support backported fixes, it recommended to use our workflow: | ||
62 | |||
63 | ```bash | ||
64 | # In master, fix the major bug | ||
65 | git commit -m "Katastrophe" | ||
66 | git push origin master | ||
67 | # Get your commit hash | ||
68 | git log --format="%H" -n 1 | ||
69 | # Create a new branch from your latest release, let's say v0.8.2-1 (the tag name) | ||
70 | git checkout -b katastrophe v0.8.2-1 | ||
71 | # Backport the fix commit to your brand new branch | ||
72 | git cherry-pick <fix commit hash> | ||
73 | git push origin katastrophe | ||
74 | # Then you just have to make a new release from the `katastrophe` branch tagged `v0.8.3-1` | ||
75 | ``` | ||