Development/Branches

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

• Wiki Home
• Development
• Design
• QA
• Events
• Documentation
• Website
• Localization
• Accessibility
• Marketing
• Diversity
• Wiki Help

• Overview
• Reporting Bugs
• How to build
• Code Overview
• Git Commands
• Debugging
• EasyHacks
• Release Plan
• FAQ
• Developers
• Extensions
• → Open Issues

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