You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 29 Next »

Introduction

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.

Goal

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.
  • 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.

    • IMPORTANT:
      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.

Developers

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

Anyone

  • 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: https://openoffice.apache.org/source.html. 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 http://svn.apache.org/viewvc/openoffice/branches/

$ svn checkout https://svn.apache.org/repos/asf/openoffice/branches/AOO413

Build with release options

Use the scripts at http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/. The 4.1.4 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 http://archive.apache.org/dist/openoffice/4.1.3/ 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)

NOTE:
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.

http://www.apache.org/legal/release-policy.html#release-signing

All files need:

Release scripts can be found at: http://svn.apache.org/viewvc/openoffice/devtools/release-scripts/

 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 settings.mk, 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 (https://dist.apache.org/repos/dist/dev/openoffice/). 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/minor.mk :

RSCREVISION
BUILD
LAST_MINOR

 

QA

  • Generic QA
    TBD

  • Specific QA focused on the selected bugfixes/enhancements
    TBD

Planning

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 http://www.apache.org/legal/release-policy.html#release-approval for the full requirements.

Uploads

  • Make sure builds are on the ASF Archive server
    NOTE:
    Hash files must not be stored on public servers but only on ASF servers. The files get copied automatically when the files get uploaded to the ASF Dist server (dist area).

  • Sourceforge: Update to "Latest Version"
    Set the attribute "Latest Version" to all full installation files for every platform.

  • Update Feed: New check.Update for the aoo<version> area. The update notification will create a high load on the mirror servers as a lot of users will then update their AOO installation. This must be avoided. Therefore this task has to be done always some days after the release.

Create new SVN tag

  1. Double-check what version was built (for 4.1.3 it's Rev. 1761381, 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 http://svn.apache.org/viewvc/openoffice/branches/ (in this case it's AOO413 and revision number is indeed 1761381) and check it is aligned (it is, since the two revisions match).
  3. SVN copy the branch to the tag. You can do it locally but it's much more efficient to do it remotely. So, from anywhere on a machine with SVN access, just run:

 

$ svn copy https://svn.apache.org/repos/asf/openoffice/branches/AOO413 https://svn.apache.org/repos/asf/openoffice/tags/AOO413 -m "AOO revision \
1761381 from branch AOO413 was voted to be released as Apache OpenOffice 4.1.3 in October 2016" 

Committed revision 1790662.

 

This results in the new tag appearing at http://svn.apache.org/viewvc/openoffice/tags/ (while at it I fixed the missing 4.1.3 tag, so I did run the command above).

Communication

Pre-Announcement

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: https://blogs.apache.org/ooo/

More things to do?

The Infrastructure team needs to know about an upcoming release to be able to prepare servers and resources and to make sure they are up and running. Write a mail to infrastructure@apache.org and tell them what can be expected (number of files, total file size, directory structure, etc.). See http://www.apache.org/legal/release-policy.html#heads-up for further details.

TBD

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.

TODO:

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

With whom to coordinate?

Currently Sally Khudairi (ASF VP, Marketing & Publicity) is responsible for press releases and general publicity help. Write a mail to press@apache.org 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 : https://blogs.apache.org/foundation/

English Press Release to the AOO Blog : https://blogs.apache.org/ooo/

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

Translations

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

  • Release Notes

  • Press Release

IMPORTANT:

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

https://www.openoffice.org/download/index.html

TBD

Main homepage

https://www.openoffice.org/index.html

TBD

Blog & News

TBD

Localized download webpages

IMPORTANT:

Every language has it's own website area that needs to be updated.

Example:

https://www.openoffice.org/xx/download/index.html

Of course the languages depend on the release. The most important languages - with it's 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, xx (template files)

TBD

Localized homepages

https://www.openoffice.org/xx/index.html

Version in the header link

TBD

Blog & News

TBD

Project's homepage

Homepage

https://openoffice.apache.org/index.html

TBD

Download webpage

https://openoffice.apache.org/downloads.html

TBD

DOAP RDF data

https://projects.apache.org/project.html?openoffice

Update the data of the following file: https://svn.apache.org/repos/asf/openoffice/site/trunk/content/doap_openoffice.rdf

Finally, don't forget to publish the website.

IMPORTANT:

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

https://reporter.apache.org/addrelease.html?openoffice

Add new release

Statistics webpage

Webpage

http://www.openoffice.org/stats/downloads.html

What has to be changed?

IMPORTANT:

The webpage itself does not need to be changed. The download numbers are taken from https://svn.apache.org/repos/asf/openoffice/ooo-site/trunk/content/stats/aoo-downloads.txt
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 https://svn.apache.org/repos/asf/openoffice/devtools/aoo-stats/README.txt for instructions how to get new download numbers.

Changes to Support Areas

Bugzilla

Prerequisite

  • 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.

IMPORTANT:

Add new revision to available list.

Update Notifications

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

IMPORTANT:

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

  • No labels