About this Page
This document outlines our process for coordinating releases of the Fluid Infusion source code and the Design Handbook. This is an archival document.
What's in a Release?
We expect that each Fluid Infusion release will contain a combination of framework code, reusable user interface components, and documentation. More specifically:
- Examples and sample code
- API documentation and tutorials
- UI Design Patterns
- UX Walkthrough checklists and techniques
- User testing guidelines
Frequency of Releases
We release versions of the Fluid Infusion 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:
- SVN tags
- 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.
Who Coordinates with the Community?
Set and announce the release date, code freeze date and bug parade date
Project Manager, Tech Lead, QA Lead
Coordinate the release deliverables and create a roadmap on the wiki
Project Manager, Tech Lead , UX Leads
Ensure known issues in JIRA have been marked with the correct fix version for the release
Create documentation JIRA issues and coordinate with community
Work with component design/development teams to produce a test plan for each Fluid component
Recruit QA testers
Create release related JIRA issues for the main release tasks, and set them as blockers (once Bug Parade is complete)
Coordinate QA and Code Freeze
Coordinate Release Bundle QA
Send release e-mail and create release news item
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, QA Lead and Documentation Lead roles can be rotating positions based on interest and expertise.
Release Status Wiki Page
Release-related JIRA issues
The real work of creating a release is managed through a number of Blocker JIRA issues. These JIRAs must be created for each release, and any necessary changes to the code must be committed against them.
During Bug Parade
Code cleanup for release x.x
Check licenses and copyrights
Update and expand on unit test coverage
Increase unit test coverage and ensure that all tests are passing.
After Bug Parade is Over
Be sure to update the version number, the zip file names (which include the version number), the "What's New" section with a list of features of the release, folder hierarchy if it has changed at all (e.g. new sample-code folders added), the list of supported browsers if it has changed, and the "Known Issues" section with highlights of the known issues.
Generate and test release bundles
Tag, package and post the release
Ensure that component progress indicators are up-to-date
The progress indicators on each component landing page should be double-checked, to ensure that they are up-to-date.
Update the demos on the Fluid website
Once the release bundle is posted, the links on the website to demos of the latest release must be updated:http://fluidproject.org/index.php/demos
For instructions, seehttp://wiki.fluidproject.org/display/fluid/Release+Process#ReleaseProcess-UpdatingDemosontheFluidProjectwebsite
Try to identify any dependencies between JIRAs (for example, the bundle must be tested before it is posted) and create these links in JIRA.
Documentation JIRA issues
To ensure that the API documentation and tutorials are up-to-date, each document needs to be reviewed. JIRA issues should be created to coordinate this process. The specific pages needed will depend on the current state of the documentation, but the JIRAs should follow the following pattern:
"Tech review of <page> docs"
A technical review of <link to actual documentation page>
Update the wiki for release
Update the website for release
NOTE: Technical review should ideally be carried out by someone who did NOT originally create the 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 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 Tag and Package the Source Code
Posting the Distribution
The distribution files must be uploaded to the websites
releases folder using
ftp. Links on the website downloads page (http://fluidproject.org/index.php/download-infusion) and the wiki downloads page will link to this location.
Speak to someone on the project core team about
Updating Demos on the Fluid Project website
- Archive the existing Demos page (http://fluidproject.org/index.php/infusion-demos) as follows:
- Create a new sub-page of 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 and ask the community to update the remaining open issues:
- The current assignee should consider the issue and decide whether or not to resolve it, assign to someone else, or change the "Fix for" version to an unreleased 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.
If you discover a security issue, follow the Fluid Security Policy and report the issue privately to the security team.