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

Compare with Current View Page History

« Previous Version 16 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 seperate 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.
  • Select issues and enhancements to go in the releases that can be accepted 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 BZ issue (? = ask for blocker, + = grant as blocker, - = deny as blocker).
    • See BZ 127103 as example.

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

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 commens 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

  • Upload to SF mirrors (Copy requires just a few hours, with the normal rsync instructions shown; note: project name has changed since 4.1.2 and now the rsync target must be written as username@frs.sourceforge.net:/home/frs/mirror/openofficeorg/4.1.3/
    IMPORTANT:
    Make sure it's going into a "staged" drectory.

  • Upload builds to ASF Dist server (dist area)
  • 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> areaThe update notification will create a high load on the mirror servers as a lot fof users wil lthen update their AOO installation. This must be avoided. Therefore this task has to be done always some days after the release.

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

More things to do?

The Infrastrucure 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.

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 immediatelly)

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

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

TBD

Main homepage

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

TBD

Blog & News

TBD

Localized download webpages

IMPORTANT:

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

Example:

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

Of course the languages depend on the release. The most important langugaes - 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

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

Version in the header link

TBD

Blog & News

TBD

Project's homepage

Homepage

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

TBD

Download webpage

http://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.

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