Development/Branches

    From The Document Foundation Wiki

    Our git repository has several branches:

    • master - the main development branch
    • libreoffice-X-Y - release branch, suited to release the X.Y product line (like libreoffice-3-4)
    • libreoffice-X-Y-Z - release branch, suited to release the concrete version (like libreoffice-3-4-0, to release 3.4.0)
    • integration/dev300_mXYZ - integration branch, to merge code from OpenOffice.org, or elsewhere [obsolete]
    • feature/NAME - topic (feature) branch, to develop a feature without changing any other branch
    • private/$GERRITUSERNAME/NAME private test branches etc.
    • distro/NAME/VERSION used by some linux distributions to manage additional patches
    • ports/PLATFORM/VERSION used for unofficial community ports, e.g. Doug's macOS 10.5 PPC port

    feature branches

    The topic branches have the rules set by the maintainer of that; they are supposed to live for a short time, and are merged into master sooner or later. They may be re-based by their owners.

    The master and release branches have more general rules, see below.

    master

    • Anything can be committed or merged into it (of course as long as the author did her best to make sure it builds and does not break the tests; running "make check" is recommended to ensure that)
    • No review required, but it's possible to ask for review by pushing to gerrit (recommended for inexperienced developers)

    libreoffice-X-Y

    • Branch created with the first beta
    • Only fixes go in, no features
      • Exception for the late features: 3 approvals from people with different affiliation than the original author
    • No review required while in beta stage/until creation of first release candidate
    • 1 review from a reviewer other than the author required after the last beta
      • the best way to get patches reviewed is to "git cherry-pick -x" a commit from the "master" and push it to gerrit (use "git cherry-pick -Xignore-all-space -x" if you get conflicts, but you think you should not)
      • Any source of the patch goes - be it a patch sent to the mailing list, pasted via pastebin, a cherry-pick from master, or cherry-pick from any other branch
      • The reviewer pushes to the branch [unless the reviewer and author agree on something else ;-)] with the appropriate Signed-off-by: tag [use the "-s" option of git commit or git cherry-pick ;-)] (or just "submit" in gerrit which adds Reviewed-by tag)
    • No merges back to anything

    libreoffice-X-Y-Z

    • Branch created with the "semifinal" RC (see the release plan)
    • Preferably just translation or blocker fixes
    • 2 additional reviews [Q: wouldn't actually just 1 additional be enough?]
    • Only cherry-picking from libreoffice-X-Y, the 2nd reviewer pushes
    • No merges back to anything