doc/md/Versioning-and-Branches.md

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