Old Release Process

Introduction

About this Page

This document outlines our process for coordinating releases of the Fluid source code and the Design Handbook. This page is currently out of date.

Frequency of Releases

We release versions of the Fluid framework, components, and Design Handbook on a monthly basis. For more information about the contents of each monthly release, check out the Fluid Community Roadmaps.

Release Version Number

Each release has a unique version number associated with it, e.g. "0.1" or "0.3beta1". This version number must be recorded consistently in a few locations:

Wiki pages and other documentation
The project pom.xml file
The ant build scripts properties file, build-scripts/build.properties
The version number of the Wiki API page snapshots
The following instructions will describe more specifically when, where and how to record the release number.

Process

As we approach an upcoming release, the following process kicks into gear:

Task	Who Coordinates with the Community?

Task	Who Coordinates with the Community?
Identify the Release Manager	Project Manager, Tech Lead
Set the release date and code freeze date	Project Manager, Tech Lead, Release Manager
Coordinate the release deliverables	Project Manager, Tech Lead , UX Leads
Work with component design/development teams to produce a test plan for each Fluid component	QA Lead
Recruit QA testers	QA Lead
Create the Release Status page	Release Manager
Update Wiki pages	Tech Lead, UX Leads
Ensure known issues in JIRA have been marked with the correct fix version for the release	Release Manager
Discuss ongoing bug fixes and commits on fluid-work	Whole Community
Ongoing QA testing and bug fixing	Whole Community
Review commits	Release Manager
Create snapshots of the wiki API documents	Release Manager
Tag and package the release	Release Manager

This is a collaborative process, and the community is encouraged to take an active role in defining schedules and coordinating the release process. It is expected that the Release Manager and QA Lead roles can be rotating positions based on interest and expertise.

About the Release Manager

The Release Manager is a volunteer from the community who agrees to be the primary point of contact for a release. The release manager's responsibilities includes:

Working with the technical lead and project manager to determine the timing of a release
Announcing the release schedule
Coordinating code freeze
- Reviewing commits
- Ensuring post-freeze commits are well-tested, filed against known JIRA bugs, and don't change public APIs
Managing the mechanics of a release, including:
- Tagging the release
- Creating a maintenance branch if necessary
- Packaging up the release
- Working with the project manager to announce the release

Release Status

Each Fluid release will have a status page, documenting the deliverables expected for the release. This includes a a list of new functionality, documentation, and the contents of the Design Handbook. The status page will also outline all of the known bugs and issues that are expected to be fixed in time for the release. The release status page should also include a summary of the goals for the release.

How to Create the Release Status Page

The following summarizes the steps to create a release status page:

In Confluence, create a new wiki page as a child of the Project Coordination page called "Fluid x.y Release Status" (where x.y is the version number).
- This can be done by copying a previous release status page, and tweaking it.
Document the release goals
Create a table outlining the release deliverables, including the status and coordinator for each deliverable
In JIRA, create a filter showing all of the open issues corresponding to the release.
Save the filter and share it publicly. This may require special access in JIRA, so ask if you need help.
Grab the URL to the RSS feed of the filter.
Use the jiraissues tag in Confluence to automatically pull in the contents of the RSS feed and display it in a table: