Branches and Their Descriptions
The following page describes the various names that we use for OpenOffice.org and the abilities of those branches. This list is not meant to be comprehensive it is just a quick snapshot.
childworkspace (cws) branches
List of Current Active branches
|Mac specific for 3.0 release
|Apple remote control support
(3.1 target release)
All branches support the following platforms:
- Linux (x86 and x86-64)
- Solaris (sparc), x86
- FreeBSD - We need a tinderbox
All branches support the following compilers:
- gcc 3.3 and higher
- jdk 1.5 and higher
Active branches for developers on the bleeding edge
This is the area for the brave and experienced developers. These branches are open for creating the next feature set. They are always flaky and almost never build without adding patches. You have been warned.
Bleeding Edge branches
|Master workspace for OOO300 cws (3.0 codeline)
|Master workspace for DEV300 cws (3.x codeline)
This is just a tracking for those that are looking up the mailing lists.
|Ongoing Version 2.0 fixes (0620 not integrated)
|Ongoing Version 2.0 fixes and patches
|cws for first round of gcc 3.4 fixes
|Preparing for 1.1.3 release
|Ongoing Version 2.0 fixes
|cws developer build including source and solver tar balls
|ongoing Version 2 fixes
|final for 1.1.1 Release
|Clean up warnings, Windows compiler release
|fixes for 1.1.1 Release
|fixes for 1.1.1 Release
|early development for 2.0
|Bugfix release OOo 1.0.x
A developers branch is where most hacking is done. This has the most open policy for applying patches and it is typically where new features are developed and debugged.
The good side to this is that you have the latest features, the down side is that you get the side effects of the changes. We don't discourage you from working here but you can expect problems at times.
Developer releases are merged back to stable on a semi regular basis. All features migrated to stable must be exactly that.
A stable branch is base for a release build of the OpenOffice.org product. This is where bug fix tracking takes place. The policy on these branches are to fix functional errors only.
The good side is that any patches are more thoroughly vetted before going into a stable release therefore you have fewer mystery bugs. The downside is that there are fewer features and some bug fixes are already in the developer release.
This branch, with the name mws_srxNNN, is the place where work from developers is integrated into the main codeline. Developers work in child workspaces with names cws_srxNNN_workspace_Name, and this work is then merged into the corresponding master workspace. Developer snapshots are released from this branch at regular intervals.
This is where a lot of porting to new platforms occurs. There are few features added in these branches and sometimes they are very outdated in terms of functionality as a port needs some stability so that they are not solving new problems but working to an end goal together.
Features that are added are to help support that platform for example adding a new way of calling windowing functions for example coding Mac OS aqua calls instead of X windows calls.
This is a branch used for platforms that are not yet part of the official release platforms, including Mac OSX, Irix, Linux s390.
A tinderbox build can be any one of the above branch types. It is executed repeatedly on your machine. This ensures that the particular branch is working on all platforms that it is supposed to work on.
The reason that a build may break on a branch is that a developer committed a patch that did not take into account another platforms. A patch that works fine on windows but breaks a Linux build and vice versa.
Comments and updates
This document is a work in progress, any comments Martin Hollmichel