This page lists the numerous actions required to make an Apache OpenOffice release happen. Initially, it will cover a simple point release, without major user interface changes. It can be expanded later to cover more cases.


Describe the actions in detail, so that everybody should be able to take over and not specific project committers and members.

The actions are sorted in specific sections and not in chronological order. This should be done in the release schedule on a separate Wiki webpage.

Short legend

  • TBD = To be defined. More details are needed to describe the task.
  • TODO = A specific detail needs to be described.

Initiating a Release

Release Manager

  • Pick a Release Manager, by lazy consensus unless there are multiple candidates.
  • Create a SVN branch from a previous branch or from trunk. This has to be discussed and agreed on the dev@ mailing list.
    From anywhere on a machine with SVN access, just run:
    $ svn copy \
    -m "Branch off 4.1.6 from HEAD of 4.1.5"

  • Select issues and enhancements to go in the releases that can be accepted as a release blocker.
  • Only the Release Manager should grant or deny requested issues:
    • This is done by setting the release blocker flag in the respective Bugzilla (BZ ) issue (? = ask for blocker, + = grant as blocker, - = deny as blocker).
    • See BZ 127168 as example.
      Make sure that your BZ user account has the permissions for the groups "relman", "qa-team", "editbugs", and "canconfirm" to be able to edit the issues as it is needed. Ask your BZ admin to get these permissions set.


  • Propose string/localization updates.
  • Propose dictionary updates.
  • Provide code for the selected bugfixes and enhancements.


  • Select bugfixes and enhancements.
  • Issues that are seen as release blocker:
    • They need to be discussed. Ideally, this takes place publicly on dev@, but security fixes must be discussed on a private mailing list.
    • Write something about why it is valid as blocker (problem situation, what needs to be fix in code, what is the risk when fixed/not fixed).

Check out the source code

The SVN usage is described in some more details here: So, just "svn checkout" the relevant branch. Starting with 4.1.3 we have been using dedicated branches, so naming is now obvious (we had been reusing branches in precedence, like AOO410 was used for 4.1.0, 4.1.1 and 4.1.2). Branches are listed at

$ svn checkout

Check versions

Note: we now have tools that will take care of this step automatically. If you can't find them, please e-mail the dev list and ask for information.

Make sure that the source files contain the correct version numbers (this should have been done when creating the new branch). In particular, check these files:

  • ./main/instsetoo_native/util/openoffice.lst
  • ./main/odk/util/makefile.pmk
  • ./main/solenv/bin/srcrelease.xml
  • ./main/solenv/inc/
  • ./main/sysui/desktop/

Build with release options

Use the scripts at The 4.1.6 scripts are correct. 

Release Candidates

Even when the created build files are Release Candidates (RC), they still belong to the Dev area. Only final releases will be uploaded to SourceForge. See the mailing list post on dev@ for more information.

Files and folders structure

See for an example. Note in particular that we have:

  • source/ - more on this below
  • binaries/ - they do include SDK, but they do NOT include kid (kid = keyID, which is a help for translators to identify specific strings)

The structure must not be changed since the scripting on the download pages assume it is identical to any former release.

Everything must come with hashes and signatures

All files need

Release scripts can be found at:

How is the source code obtained?

It is not obtained via SVN export as one could imagine. You get it in a source tree by running:

$ cd instsetoo_native/util
$ dmake aoo_srcrelease

Be sure to source the required env file first. If you get an error about not finding, that's the problem. We still get the three formats (zip, gz, bz2). This will probably change with newer release branches than 4.1.x as discussed a long time ago, but for now we should still use the three of them.

How are packages uploaded?

It is going to be a huge SVN commit to the dev area ( Experience from a couple years ago:

  • The SVN server has good reliability but it is slow, much slower than you would expect.
  • First, assemble the tree in one location. E.g., setup a space on fast-connected server where people uploaded their builds. This is the best option, otherwise people will have to wait for each other and do a full checkout (slow and huge).
  • Then structure files/folders as above.
  • Now do the SVN commit. Due to speed issues, it is recommended to script this and upload one language at a time - unless the SVN server speed has increased dramatically, but still you need one minute to script it, so it is worth doing. For comparison, the SVN server was reliable but the gigantic SVN commit took something like 20 hours from a machine that had no bandwidth problems; script it and be safe (even if it could be expected that speed is better now).

Subsequent RCs

When going from, for example, RC1 to RC2, be sure to bump the build numbers in main/solenv/inc/ :



  • Generic QA

  • Specific QA focused on the selected bugfixes/enhancements


Document the planning details

Do the binaries builds

Building the software

  • Buildbots
  • Windows builds
  • Mac OS X 64-bit builds
  • Linux 32-bit DEB+RPM builds
  • Linux 64-bit DEB+RPM builds
  • SDK builds
  • Source builds

Release Vote

Before uploading to any non-development location, the release must pass a vote. Almost all users depend on the binary builds, so those must be tested as extensively as possible. Anyone can do testing, and cast an advisory vote. Non-binding, advisory votes and their comments can and should influence the Release Manager's final decision on whether to turn a release candidate into a release.

PMC members can cast a binding vote, but each PMC member casting a binding +1 vote must have personally built from source and tested on a computer controlled by the PMC member. ASF rules require at least three binding +1 votes for a release. See for the full requirements.




Notifying or not?

Do we want to notify the world that a new release is cooking:

  • What is coming?
  • Some details?
  • When does it come?

If yes, write first status update and call for volunteers on dev@ mailing list and on the AOO Blog:

Release Notes

Requires a Confluence account that can edit OpenOffice pages. Create a page for the release as a child of Releases. Select that page, click "Create" in the Confluence menu bar, and create a blank page. Copy the planning for a previous release. Under that page, create a release notes page that can also start as a copy of prior release notes. Edit to reflect reality.


Create templates for the release planning and release notes pages.

A template for the Release Notes has been available since 2016-08-03.

  • Short User Guide coming soon

ASF Press Release

Coordinate with the ASF VP, Marketing & Publicity

Currently Sally Khudairi is responsible for press releases and general publicity help. Write a mail to and ask for help. Then she will answer with further steps.

Where to do the announcements?

English Release Notes : AOO <version> Release Notes

English Press Release :

English Press Release to the AOO Blog :

Announce mail : Write to announce@ (every mail needs to be moderated, so don't expect to arrive immediately)


The following documents  should be made available for translation, and :

  • Release Notes
  • Press Release


Give translators a heads-up of 48 hours before the release should happen. This should enable a parallel press release.

Changes to Webpages

Main download webpage


Main homepage


Blog & News


Localized download webpages


Every language has its own website area that needs to be updated.


Of course the languages depend on the release. The most important languages - with its ISO codes are the following (ordered by download popularity):

en-US, fr, de, it, es, ja, ru, pl, nl, zh-TW, cs, zh-CN, el, pt, da, no

Do not forget the template files with code "xx".


Localized homepages

Project's homepage



Download webpage


Apache's project data (DOAP RDF data)

Update the data of the following file:

This file is located on the project website, which is self-publishing. Just make sure you do the changes in one commit.


The new data is not shown after it was published. There is a delay due to a cron job that runs maybe every 24h.

Apache Committee Report Helper

Add the new release with exact version number and full date.

Statistics webpage

In order to get also the downloads for the new release counted the following changes have to be done:


The webpage itself does not need to be changed. The download numbers are taken from
The file just needs to be updated with new numbers. As soon as the file is then committed and the website published, the new download numbers are shown in the chart.

Please see for instructions how to get new download numbers.

Tasks after the release is public

Create new SVN tag


Do not create any SVN tag as long as the release is not officially announced and public available. Otherwise the created build files cannot be published when a late show stopper will be found. This must be avoided in any case.

When to do

The best time to do it is when the press announcement is published and the installed files are available on the download webpage.

What to do

  1. Double-check what version was built (for 4.1.6 it is revision 1844436, you find it even in the About Box). Of course, if this happens during the release process, the Release Manager knows it.

  2. Find the relevant branch in (in this case it is AOO416 and revision number is indeed 1844436) and check it is aligned (it is, since the two revisions match).
  3. SVN will copy the branch to the tag. You can do it locally but it is much more efficient to do it remotely. So, from anywhere on a machine with SVN access, just run:
$ svn copy -m "AOO revision \
1844436 from branch AOO416 was voted to be released as Apache OpenOffice 4.1.6 on November, 18th, 2018"

Committed revision 1844437.

This results in the new tag appearing at



This requires admin privileges on Bugzilla

What has to be changed?

  • Add new version to the UI field "Version". This has to be done for every active product via "Edit versions".
  • Deactivate (don't delete) previous version in the UI field "Milestone". This has to be done for every active product via "Edit milestones". Because the previously released version is done and will not be updated, then it shouldn't be able to choose it.
  • Add new version to the UI field "Latest Confirmation via the custom field "cf_lastconfirmedver". This needs to be set only ones which is used for all products.


Add new revision to available list.

Apache Project Checker

After the new release is published and announced, the Release Manager should have a look at the project checker to make sure that there are no problems:

What has to be checked?

  • The section "problems" should have a green "none".
  • The section "status" should have a green "perfect".
  • The section "signing keys" should list all keys with "GOODSIG".
  • The section "signature status" should list with "GOODSIG" and "sig is ok".

In general, all data listed on the webpage should make sense and does not point to a problem.

When to do this?

It depends on the following:

All together, doing this after the release is announced should be enough.

Delete the previous release

OpenOffice is using a lot of space for each release. To keep it at a minimum it was agreed with the Infrastructure team to delete the previous release when the new one is published and no problems arose in a short time frame.

What has to be done?

Make sure that on is only the new release. Delete the older release


svn delete

When to do this?

Also here, doing this after the release is announced should be enough.

Update Notifications

Change update script so users are notified of new version when they start AOO:


Usually done 1 - 3 weeks after the formal announcement to avoid a high traffic load on the SourceForge mirror servers which must be avoided.

  • No labels