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 Project 2007-9 Project Plan.
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
antbuild scripts properties file,
- 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.
As we approach an upcoming release, the following process kicks into gear:
Who Coordinates with the Community?
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
Recruit QA testers
Tech Lead, UX Leads
Ensure known issues in JIRA have been marked with the correct fix version for the release
Discuss ongoing bug fixes and commits on fluid-work
Ongoing QA testing and bug fixing
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:
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:
Updating the Wiki for Release
Updating Wiki: Development
- Update any development API and integration pages.
- Update any demos
- House cleaning - Delete any unnecessary pages and information created in this past iteration.
- Update download & component pages (see below)
Release download pages
- Consider putting a disclaimer at the top of any affected pages, with the following text (or something similar):
- "This page is currently being edited in preparation for the pending X.X release. It's contents should be considered in flux and unreliable until this warning is removed. For the latest stable release, see Fluid Infusion X.X."
- Duplicate the old Fluid Infusion - Current Release page into a new page called "Fluid Infusion X.X" where X.X is the old release number.
- _This new page should be a child of Fluid Infusion - Current Release.
- Update Fluid Infusion - Current Release to the latest release.
- Be mindful to follow the excerpt format. The links to the bundles at the top will be excerpted, and displayed on the Downloads and Demos page.
- Update the Downloads and Demos page to reflect any new demos that are now available.
- Go to the Components page
- For each Component that was updated in this release, ensure that the relevant information page is updated.
- Update API, Integration, Demo, and Testing sections as necessary.
Updating Wiki: UX
- House cleaning - Delete any unnecessary design information (pages, notes, etc) added to the Wiki in this past iteration.
- Update any Components pages to reflect the current state of the design.
- Wireframes, Storyboards, Design pattern, Functional Req, User Testing, Story Cards, User modeling, Accessibility.
- Verify that any changes to the Design Handbook is reflected.
How to Create a Snapshot of the Wiki API Pages
When all the pages have been snapshotted, edit the Table of Content page to reference the new versioned docs.
How to Tag and Package the Source Code
How to Tag the Source Code
Note that the Fluid-0.1 release is used as an example in what follows. If you are using these instructions for another release, remember to substitute the correct version number for occurrences of "0.1".
and update the version to reflect the new version now in Fluid's trunk.
How to Package the Source Code
The steps to package the source code are:
- Check out a fresh, clean copy of the tagged version of the source code.
svn co https://source.fluidproject.org/svn/fluid/components/tags/fluid-0.1 fluid-0.1
cdinto the build scripts folder (
fluid-0.1/build-scripts) and run the
anttask to build the release bundle:
This creates a folder called
productsand places the release bundles there:
- This zip file should contain the license files, as well as source, examples, and the war file.
- Test the distribution file thoroughly by unpacking it into a clean environment and running all tests, etc.
Posting the Distribution
Updating Demos on the Fluid Project website
- Archive the existing Demos page: create a new sub page to the Demos page and copy and paste the Demos page content there.
- Extract a copy of the new minified source code and demos into the new releases' directory. (i.e. ~/website/docs/releases/0.999beta1)
- update the Demos page links to reference the new sample code.
- add any new Demos
- Add a link from the Demos page to the Demos just archived in Step 1. Put this link under the "Past Releases" section at the bottom of the page.
- Mark the version released, moving remaining open issues to the next version.
- Do a query for all unresolved issues that affect the previous release and release candidates. Add the new release version as an affected version for each issue in the results.
Managing Unexpected Issues
Bugs happen. When unexpected issues or problems arise, the Release Manager, Technical Lead, or Project Manager will inform the community and work with them to adjust the release schedule accordingly. If you find an issue that you think is a blocker, let the Release Manager know as soon as possible.