|
1 | 1 | Branch policies
|
2 | 2 | ===============
|
3 | 3 |
|
4 |
| -Branchs |
5 |
| -+++++++ |
| 4 | +This document describes the branching model used in LibreSign and how contributions should be targeted. |
| 5 | + |
| 6 | +Branch Names |
| 7 | +------------ |
6 | 8 |
|
7 | 9 | Main
|
8 |
| ----- |
| 10 | +^^^^ |
| 11 | +The ``main`` branch is the **default development branch** of LibreSign, equivalent to the ``master`` branch in the Nextcloud Server repository. |
| 12 | + |
| 13 | +- Code in ``main`` represents the **next stable release** of LibreSign, which aligns with the **next stable release** of the Nextcloud Server. |
| 14 | +- Development in ``main`` must follow the `Nextcloud Server Maintenance and Release Schedule <https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule>`_ to ensure compatibility and coordinated releases. |
| 15 | +- New features and general changes are developed in short-lived branches created from ``main`` and merged back through reviewed pull requests. |
| 16 | +- **Bug fixes**: |
9 | 17 |
|
10 |
| -The main branch is the default branch for the repository. It is used for production-ready code and should always be stable. All changes to the main branch should be made through pull requests, which must be reviewed and approved by at least one other developer before merging. |
| 18 | + - If a fix affects **all supported versions**, implement it in ``main`` and backport it to the relevant stable branches. |
| 19 | + - If a fix is **specific to a single stable line**, implement it only in that stable branch. |
| 20 | + |
| 21 | +- The ``main`` branch is **not intended for production use**; it contains code under active development for the upcoming release. |
11 | 22 |
|
12 | 23 | Stables
|
13 |
| -------- |
| 24 | +^^^^^^^ |
| 25 | +Stable branches maintain release lines compatible with a specific **Nextcloud Server** major version. |
| 26 | + |
| 27 | +- Branch names follow the format ``stableXX``, where ``XX`` is the **MAJOR** version of the supported Nextcloud Server. |
| 28 | + |
| 29 | + - Example: ``stable21`` → compatible with Nextcloud 21. |
| 30 | + |
| 31 | +- Create a new stable branch when a new Nextcloud Server major version is released and LibreSign will support it. |
| 32 | +- **To identify which Nextcloud Server version a stable branch supports**: |
| 33 | + |
| 34 | + 1. Checkout the branch locally or open it in GitHub. |
| 35 | + 2. Open the file ``appinfo/info.xml``. |
| 36 | + 3. Look for the ``<nextcloud>`` element: |
| 37 | + |
| 38 | + .. code-block:: xml |
| 39 | +
|
| 40 | + <nextcloud min-version="21" max-version="21" /> |
| 41 | +
|
| 42 | + In LibreSign, ``min-version`` and ``max-version`` are always the same number. |
| 43 | + This number is the MAJOR version of the compatible Nextcloud Server. |
| 44 | + |
| 45 | +Target Branches for Contributions |
| 46 | +--------------------------------- |
| 47 | + |
| 48 | +- **New features / improvements**: |
| 49 | + |
| 50 | + - Create a branch from ``main``. |
| 51 | + - Open a PR to ``main``. |
| 52 | + |
| 53 | +- **Bug fix affecting all supported versions**: |
| 54 | + |
| 55 | + - Create a branch from ``main``. |
| 56 | + - Open a PR to ``main``. |
| 57 | + - Backport to all affected stable branches. |
| 58 | + |
| 59 | +- **Bug fix specific to a stable**: |
| 60 | + |
| 61 | + - Create a branch from that stable branch. |
| 62 | + - Open a PR to the same stable branch. |
| 63 | + |
| 64 | +Bugfixes and Backports |
| 65 | +---------------------- |
| 66 | +If a bug fix also needs to be applied to an older release line, it must be **backported**. |
| 67 | +Backporting means applying the same change to another branch (Git calls this *cherry-picking*). |
| 68 | + |
| 69 | +Automatic Backport |
| 70 | +^^^^^^^^^^^^^^^^^^ |
| 71 | +If the cherry-pick applies cleanly and only small conflicts need to be resolved, the `backport bot <https://github.com/nextcloud/backportbot>`_ can be used. |
| 72 | + |
| 73 | +See the `bot usage <https://github.com/nextcloud/backportbot#usage>`_ for available commands. |
| 74 | + |
| 75 | +Manual Backport |
| 76 | +^^^^^^^^^^^^^^^ |
| 77 | +For more complex changes, the backport must be done manually: |
| 78 | + |
| 79 | +.. code-block:: bash |
| 80 | +
|
| 81 | + # Switch to the target branch and update it |
| 82 | + git checkout stable25 |
| 83 | + git pull origin stable25 |
| 84 | +
|
| 85 | + # Create the new backport branch |
| 86 | + git checkout -b fix/foo-stable25 |
| 87 | +
|
| 88 | + # Cherry-pick the change from the commit SHA of the original PR in main |
| 89 | + git cherry-pick abc123 |
14 | 90 |
|
15 |
| -The stables branches are used for maintaining stable releases of the code. |
| 91 | + # Resolve any conflicts, commit, and push |
| 92 | + git push origin fix/foo-stable25 |
16 | 93 |
|
17 |
| -Creating branch |
18 |
| -+++++++++++++++ |
| 94 | + # Open a pull request for the backport |
19 | 95 |
|
20 |
| -* 1. Folow the conevention of naming branches as ``feature/description`` or ``bugfix/description``. |
| 96 | +Creating Branch |
| 97 | +--------------- |
| 98 | +Follow the convention of naming branches as ``feature/description`` or ``bugfix/description``. |
0 commit comments