Knah-Tsaeb/MyShaarli
Knah-Tsaeb/MyShaarli
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity
MyShaarli/doc/md/dev/Versioning.md
nodiscc 91a21c2729 **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
2020-09-12 14:31:45 +02:00

2.7 KiB
Raw Blame History

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 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 (Draft means not released yet) and the commit log (like tpl folder 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:

# 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 <fix commit hash>
git push origin katastrophe
# Then you just have to make a new release from the `katastrophe` branch tagged `v0.8.3-1`