About this Page
This document outlines our process for coordinating releases of the Fluid source code and the UX Toolkit.
On this Page:
What's in a Release?
We expect that each Fluid 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
Fluid intends to release versions of the Fluid framework, components, and UX Toolkit on a roughly quarterly basis. For more information about the specific timing of our releases, check out the Fluid Project 2007-9 Project Plan. The choice to release on a quarterly basis was made in order to:
- Ensure that we test regularly
- Regularly produce the important "collateral" material required to successfully use our code:
- Quality assurance tests
- Fixes and work arounds for known issues
- Provide stable, tested snapshots of our current progress in an easy-to-use form
- Ease integration with Sakai, uPortal, and our other collaborating projects
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
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:
- 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
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 UX Toolkit. 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."
- 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:
How to Generate the PDF Documentation
The PDF documentation is generated by exporting relevant pages from the wiki. The wiki pages to include are generally categorized under "API Documents," "Tutorials" and "UX Toolkit."
The resulting PDF document will be included in the zip file with the source and examples.
How to Export the Wiki Pages
- Label the relevant wiki pages with the label "release."
- The parent-child relationship of wiki pages will be reflected in the resulting PDF document table of contents. It is recommended that drafts of the PDF be checked for a reasonable structure, and if necessary, the parent-child relationships on the wiki be adjusted (note that this won't affect links within wiki pages).
- Produce a list of all the labelled pages, and keep it on hand.
- Export only the labelled pages:
- On the wiki, go the the Advanced subsection of the Browse Space section.
- Choose "Export Space"
- For 'Export format' choose "PDF Output"
- Turn off any extra options
- Clear all of the checked pages, then check only the pages labelled "release" (refer to the list you kept on hand. You kept it on hand, right?)
- Click the "Export" button at the bottom of the page.
- Rename the resulting PDF file to "Fluid-X.Y.pdf"
- Edit the PDF file:
- Change the "Space Details" title to "Fluid Infusion vX.Y"
- Replace the box containing details with a paragraph that says
- Change "Available Pages" to "Contents"
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".
The steps to tag the source code are:
- Impose a source code repository freeze until the source code is tagged. Announce the freeze on the fluid-work mailing list (email@example.com).
- Users are prohibited from committing to the source code repository trunk while the tagging operation is under way.
- Modify the release information in the maven project file(s) (pom.xml).
- Set the contents of the
<version>tag as appropriate, for example:
- Commit this project file to the repository.
- Set the contents of the
- Check out a fresh, clean working copy of the source code from the trunk.
- Using this working copy, ensure that the build works.
- The build should create a war file containing the fluid components. The war file is created in
.../fluid-0.1/target/fluid-components-0.1.war, and is copied to the local maven 2 repository,
- Run the jsUnit tests, and ensure that all succeed.
- Tag the source with the release version number.
- Note that the above assumes that "fluid-0.1" is the directory containing the maven project file with the correct release version tag.
- Modify the
versionof the maven project on trunk to reflect that trunk development is now a snapshot of the next release version. For example:
- Commit the trunk's modified maven project file.
- Lift the prohibition of committing to the trunk of the repository by announcing same on the fluid-work mailing list (firstname.lastname@example.org).
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.
- Place the PDF documentation file in the root folder (i.e. as a sibling of the
- Build the "fluid-components" folder and war file for distribution. The "fluid-components" folder is created in
.../fluid-0.1/target/fluid-components-0.1/fluid-componentsand war file is created in
- Add the "fluid-components" folder and war file to the Fluid-0.1.zip file.
- This zip file also contains documentation generated from the wiki, and a README.txt file.
- Creating a link to the zip file on the Downloads page.
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.