Release Process - Bug Parade

As the release date approaches, general work on features should stop and work should focus only on fixing existing bugs and other release-specific preparations. This requires coordination; this page describes the tasks that should be carried out for and during Bug Parade.

Create Release-related JIRAs

The real work of creating a release is managed through a number of Blocker JIRA issues. These JIRAs must be created for each release during Bug Parade, and any necessary changes to the code must be committed against them.

Bug Parade

Issue Title	Issue Description
Code cleanup for release x.x	Clean up comments, ensure public APIs are fully commented and JSLint new javascript files. Note that this issue should only be in force before Code Freeze. Commits that alter actual code should not be permitted during Code Freeze.
Check licenses and copyrights	Ensure all javascript files have a license and copyright. Also make sure thirdparty code is compatibly licensed and a license file is included in the same directory as the code.
Update and expand on unit test coverage	Increase unit test coverage and ensure that all tests are passing.
Update all version numbers for the release	All references to the version number must be updated to the new version number. This includes: package.json, all *.js files, "fluid.version" in Fluid.js
Comment any "unsupported" functions/variables/etc	Anything in our code that is "unsupported" (i.e. not meant for public use despite the fact that technically it is public) needs to be indicated as such in the comments in the code. This covers public free functions i.e. functions in the public namespace, such as fluid.inlineEdit.foo() methods and instance variables on an object returned by a creator function options defined in a defaults block or otherwise processed in the code but not for public use return values Please a comment in the code mentioning that the method/function/option/argument/return value is unsupported, and perhaps an explanation of why. Anything unsupported will not be publicly documented.
Update the README.txt and ReleaseNotes.txt files	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.
Turn off debug mode	Update fluid.fail() to throw an error, turn off debug mode for the renderer, etc.
screen source files for DOS line ending This should be handled by git	Run source tree through an utility like dos2unix to normalize line endings for Unix. See note below for more information.

Removing DOS CR/LF

For Ubuntu using fromdos command:

find . -type -exec fromdos '{}' \;

Get fromdos by running sudo apt-get install tofrodos.
back to top

Coordinate Bug Parade

The bug parade involves a concentrated period of community-wide bug squashing. We focus on a set of the highest-priority open issues that affect components in the upcoming release. These inevitably include, but are not limited to critical and blocker bugs.

The amount of time spent in bug parade is variable, dependent on the number of high priority issues. The amount of time is set before the start of bug parade, by the Tech Lead, QA Lead, and or Project Manager, and can be lengthened or shortened as needed.

Please see the Coding and Commit Standards wiki page for the commit policy during bug parade.

Jira

Tagging

All jira issues that are to be part of the bug parade should be tagged with "Bug Parade", in either the jira description or as a comment to the jira.

It is important that if a jira is no longer to be on the bug parade, that the tag be removed.

Filtering

Two jira filters should be created: "Bug Parade (all)" and "Bug Parade (open)". The first filter will show all jiras tagged for the bug parade for the current release, the second will show only those which are still open.

Reporting

The "Bug Parade (all)" filter should be converted into a "Single Level Group By Report", sorted by component.

Notification

The bug parade links to the filters and report, must be provided to the community via the fluid-work mailing list. It should also be linked to from the Release Status page.

Prepare for QA

Update Test Plans

Work with component design/development teams to ensure that component test plans are updated to reflect any changes in component behaviour.

Recruit QA testers

The Fluid community should be relied on for testing assistance. The best way to obtain testing help is through the fluid-work mailing list and the #fluid-work:matrix.org.

back to top