From 91a21c272960889afd4eaa431a3d29b7785b6efc Mon Sep 17 00:00:00 2001 From: nodiscc Date: Sat, 16 May 2020 12:54:51 +0200 Subject: **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 --- doc/md/dev/Versioning.md | 63 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 doc/md/dev/Versioning.md (limited to 'doc/md/dev/Versioning.md') diff --git a/doc/md/dev/Versioning.md b/doc/md/dev/Versioning.md new file mode 100644 index 00000000..32c80a5c --- /dev/null +++ b/doc/md/dev/Versioning.md @@ -0,0 +1,63 @@ +# Versioning + +If you're maintaining a 3rd party tool for Shaarli (theme, plugin, etc.), It's important to understand how Shaarli branches work ensure your tool stays compatible. + + +## `master` branch + +The `master` branch is the development branch. Any new change MUST go through this branch using Pull Requests. + +Remarks: + +- This branch shouldn't be used for production as it isn't necessary stable. +- 3rd party aren't required to be compatible with the latest changes. +- Official plugins, themes and libraries (contained within Shaarli organization repos) must be compatible with the master branch. + + +## `v0.x` branch + +The `v0.x` branch points to the latest `v0.x.y` release. + +If a major bug affects the original `v0.x.0` release, we may [backport](https://en.wikipedia.org/wiki/Backporting) a fix for this bug from master, to the `v0.x` branch, and create a new bugfix release (eg. `v0.x.1`) from this branch. + +This allows users of the original release to upgrade to the fixed version, without having to upgrade to a completely new minor/major release. + + +## `latest` branch + +This branch point the latest release. It recommended to use it to get the latest tested changes. + + +## Releases + +For every release, we manually generate a .zip file which contains all Shaarli dependencies, making Shaarli's installation only one step. + + +## Advices on 3rd party git repos workflow + +### Versioning + +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: + + - 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. + - use your own versioning scheme, and state Shaarli compatibility in the release description. + +Using this, any user will be able to pick the release matching his own Shaarli version. + +### Major bugfix backport releases + +To be able to support backported fixes, it recommended to use our workflow: + +```bash +# In master, fix the major bug +git commit -m "Katastrophe" +git push origin master +# Get your commit hash +git log --format="%H" -n 1 +# Create a new branch from your latest release, let's say v0.8.2-1 (the tag name) +git checkout -b katastrophe v0.8.2-1 +# Backport the fix commit to your brand new branch +git cherry-pick +git push origin katastrophe +# Then you just have to make a new release from the `katastrophe` branch tagged `v0.8.3-1` +``` -- cgit v1.2.3