<p>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.</p>
<p>The <code>master</code> branch is the development branch. Any new change MUST go through this branch using Pull Requests.</p>
<p>Remarks:</p>
<ul>
<li>This branch shouldn't be used for production as it isn't necessary stable.</li>
<li>3rd party aren't required to be compatible with the latest changes.</li>
<li>Official plugins, themes and libraries (contained within Shaarli organization repos) must be compatible with the master branch.</li>
<li>The version in this branch is always <code>dev</code>.</li>
</ul>
<h2id="v0x-branch"><code>v0.x</code> branch</h2>
<p>This <code>v0.x</code> branch, points to the latest <code>v0.x.y</code> release.</p>
<p>Explanation:</p>
<p>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.</p>
<p>In this case, the issue is fixed in the <code>master</code> branch, and the fix is backported the to the <code>v0.x</code> branch. Then a new release is made from the <code>v0.x</code> branch.</p>
<p>This workflow allow us to fix any major bug detected, without having to release bleeding edge feature too soon.</p>
<p>The <code>stable</code> branch doesn't contain any major bug, and is one major digit version behind the latest release.</p>
<p>For example, the current latest release is <code>v0.8.3</code>, the stable branch is an alias to the latest <code>v0.7.x</code> release. When the <code>v0.9.0</code> version will be released, the stable will move to the latest <code>v0.8.x</code> release.</p>
<p>Remarks:</p>
<ul>
<li>Shaarli release pace isn't fast, and the stable branch might be a few months behind the latest release.</li>
</ul>
<h2id="releases">Releases</h2>
<p>Releases are always made from the latest <code>v0.x</code> branch.</p>
<p>Note that for every release, we manually generate a tarball which contains all Shaarli dependencies, making Shaarli's installation only one step.</p>
<h2id="advices-on-3rd-party-git-repos-workflow">Advices on 3rd party git repos workflow</h2>
<h3id="versioning">Versioning</h3>
<p>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 <ahref="https://github.com/shaarli/Shaarli/releases">changelog</a> (<em>Draft</em> means not released yet) and the commit log (like <ahref="https://github.com/shaarli/Shaarli/commits/master/tpl/default"><code>tpl</code> folder</a> for themes)). You can either:</p>
<ul>
<li>use the Shaarli version number, with your repo version. For example, if Shaarli <code>v0.8.3</code> is released, publish a <code>v0.8.3-1</code> release, where <code>v0.8.3</code> states Shaarli compatibility and <code>-1</code> is your own version digit for the current Shaarli version.</li>
<li>use your own versioning scheme, and state Shaarli compatibility in the release description.</li>
</ul>
<p>Using this, any user will be able to pick the release matching his own Shaarli version.</p>
Built with <ahref="http://www.mkdocs.org">MkDocs</a> using a <ahref="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <ahref="https://readthedocs.org">Read the Docs</a>.
