**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

1 files changed, 0 insertions, 161 deletions

diff --git a/doc/md/Release-Shaarli.md b/doc/md/Release-Shaarli.md
deleted file mode 100644
index e22eabc9..00000000
--- a/doc/md/Release-Shaarli.md
+++ /dev/null
@@ -1,161 +0,0 @@
-See  [Git - Maintaining a project - Tagging your 
-releases](http://git-scm.com/book/en/v2/Distributed-Git-Maintaining-a-Project#Tagging-Your-Releases).
-
-## Prerequisites
-This guide assumes that you have:
-
-- a GPG key matching your GitHub authentication credentials
-    - i.e., the email address identified by the GPG key is the same as the one in your `~/.gitconfig` 
-- a GitHub fork of Shaarli
-- a local clone of your Shaarli fork, with the following remotes:
-    - `origin` pointing to your GitHub fork
-    - `upstream` pointing to the main Shaarli repository
-- maintainer permissions on the main Shaarli repository, to:
-    - push the signed tag
-    - create a new release
-- [Composer](https://getcomposer.org/) needs to be installed
-- The [venv](https://docs.python.org/3/library/venv.html) Python 3 module needs to be installed for HTML documentation generation.
-
-## GitHub release draft and `CHANGELOG.md`
-See http://keepachangelog.com/en/0.3.0/ for changelog formatting.
-
-### GitHub release draft
-GitHub allows drafting the release note for the upcoming release, from the [Releases](https://github.com/shaarli/Shaarli/releases) page. This way, the release note can be drafted while contributions are merged to `master`.
-
-### `CHANGELOG.md`
-This file should contain the same information as the release note draft for the upcoming version.
-
-Update it to:
-
-- add new entries (additions, fixes, etc.)
-- mark the current version as released by setting its date and link
-- add a new section for the future unreleased version
-
-```bash
-$ cd /path/to/shaarli
-
-$ nano CHANGELOG.md
-
-[...]
-## vA.B.C - UNRELEASED
-TBA
-
-## [vX.Y.Z](https://github.com/shaarli/Shaarli/releases/tag/vX.Y.Z) - YYYY-MM-DD
-[...]
-```
-
-
-## Increment the version code, update docs, create and push a signed tag
-### Update the list of Git contributors
-```bash
-$ make authors
-$ git commit -s -m "Update AUTHORS"
-```
-
-### Create and merge a Pull Request
-This one is pretty straightforward ;-)
-
-### Bump Shaarli version to v0.x branch
-
-```bash
-$ git checkout master
-$ git fetch upstream
-$ git pull upstream master
-
-# IF the branch doesn't exists
-$ git checkout -b v0.5
-# OR if the branch already exists
-$ git checkout v0.5
-$ git rebase upstream/master
-
-# Bump shaarli version from dev to 0.5.0, **without the `v`**
-$ vim shaarli_version.php
-$ git add shaarli_version
-$ git commit -s -m "Bump Shaarli version to v0.5.0"
-$ git push upstream v0.5
-```
-
-### Create and push a signed tag
-```bash
-# update your local copy
-$ git checkout v0.5
-$ git fetch upstream
-$ git pull upstream v0.5
-
-# create a signed tag
-$ git tag -s -m "Release v0.5.0" v0.5.0
-
-# push it to "upstream"
-$ git push --tags upstream
-```
-
-### Verify a signed tag
-[`v0.5.0`](https://github.com/shaarli/Shaarli/releases/tag/v0.5.0) is the first GPG-signed tag pushed on the Community Shaarli.
-
-Let's have a look at its signature!
-
-```bash
-$ cd /path/to/shaarli
-$ git fetch upstream
-
-# get the SHA1 reference of the tag
-$ git show-ref tags/v0.5.0
-f7762cf803f03f5caf4b8078359a63783d0090c1 refs/tags/v0.5.0
-
-# verify the tag signature information
-$ git verify-tag f7762cf803f03f5caf4b8078359a63783d0090c1
-gpg: Signature made Thu 30 Jul 2015 11:46:34 CEST using RSA key ID 4100DF6F
-gpg: Good signature from "VirtualTam <virtualtam@flibidi.net>" [ultimate]
-```
-
-## Publish the GitHub release
-### Update release badges
-Update `README.md` so version badges display and point to the newly released Shaarli version(s), in the `master` branch.
-
-### Create a GitHub release from a Git tag
-From the previously drafted release:
-
-- edit the release notes (if needed)
-- specify the appropriate Git tag
-- publish the release
-- profit!
-
-### Generate and upload all-in-one release archives
-Users with a shared hosting may have:
-
-- no SSH access
-- no possibility to install PHP packages or server extensions
-- no possibility to run scripts
-
-To ease Shaarli installations, it is possible to generate and upload additional release archives,
-that will contain Shaarli code plus all required third-party libraries.
-
-**From the `v0.5` branch:**
-
-```bash
-$ make release_archive
-```
-
-This will create the following archives:
-
-- `shaarli-vX.Y.Z-full.tar`
-- `shaarli-vX.Y.Z-full.zip`
-
-The archives need to be manually uploaded on the previously created GitHub release.
-
-### Update `stable` and `latest` branches
-
-```
-$ git checkout latest
-# latest release
-$ git merge v0.5.0
-# fix eventual conflicts
-$ make test
-$ git push upstream latest
-$ git checkout stable
-# latest previous major
-$ git merge v0.4.5 
-# fix eventual conflicts
-$ make test
-$ git push upstream stable
-```