Release Process - Plan the Release

Planning a release is really an ongoing affair, but there are particular tasks which should be carried out at particular times. This page describes those tasks.

Set Dates

Set and announce the

release date: based on tasking estimates for the work that is expected to be completed for the release
code freeze date: typically two full days before release
bug parade date: typically one week before code freeze

Planning the Release

These dates should be decided on individually for each release, based on the amount and nature of the work that is planned for the release. Note that for minor point releases focused mainly on bug fixes, there may essentially only be bug parade, and QA may be restricted to only particular areas of the code.

Announcement can be accomplished via

publishing of the Release Status page.
updating the Fluid Project Google calendar
discussions at developer meetings.

back to top

Create Roadmap

Using the overall project plan, the current state of the system and upcoming requirements, the project manager, community lead and architect will determine a specific roadmap for the release. This will be posted on the wiki and communicated at a developer meeting.

Create or update the roadmap on the wiki to provide an up to date view of the release
Talk about the roadmap with the community at a developer meeting

back to top

Create Release Status Page

Based on the roadmap and available resources, a timeline for the release is created. This is put onto the wiki in a release status page. Filters are also created on this page to give an overview of the release.

Create a child page of the Project Coordination page that is a copy of the previous release status page
Update the link to the current roadmap
Update the timeline
Update the What's New section with high level plan
Update the checklist to communicate the current release status
Create a public JIRA filter for all issues with a "Fix For" of the current release
Add a link to this JIRA filter on the Release Status page.
Link to the new Release Status page from the Project Coordination page

back to top

Update JIRA

Set Fix-for versions

Once the roadmap has been decided upon, update the JIRA issues for the work: Set the "Fix for" version to the release number. If no JIRAs exist for planned work, create them.

Create Documentation JIRAs

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:

Issue Title	Issue Description
"Tech review of <page> docs" where <page> may be <component> API <component> Tutorial a framework section, such as Events, Subcomponent, or Renderer etc.	A technical review of <link to actual documentation page> Check page for correctness against current code base: function signatures options (selectors, supported events, styles, etc.) dependencies etc. Check links between pages, add and update where appropriate. NOTE: Technical review should ideally be carried out by someone who did NOT originally create the page!
Migration guide from version x.x to y.y	Document any migration steps needed including: deprecations, API changes, and etc.
Update the wiki for release	See below for for details
Update the website for release	See below for details

Update version numbers in the source code

After a release has been tagged and packaged, the "current" version number in the source code needs to be updated.

Set the version number to "X.X.X" (where X.X.X is the release being planned) in

the version in the package.json file
the version numbers in the ReleaseNotes.md file
the version string in Fluid.js, in the framework code
the version number in the fluid variable declaration at the top of each .js file
tests/manual-tests/framework/core/multipleVersions/index.html

back to top