Jump to content

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