Skip to end of metadata
Go to start of metadata

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.

  1. Create or update the roadmap on the wiki to provide an up to date view of the release
  2. 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.

  1. Create a child page of the Project Coordination page that is a copy of the previous release status page
  2. Update the link to the current roadmap
  3. Update the timeline
  4. Update the What's New section with high level plan
  5. Update the checklist to communicate the current release status
  6. Create a public JIRA filter for all issues with a "Fix For" of the current release
  7. Add a link to this JIRA filter on the Release Status page.
  8. 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.yDocument 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


 

 

  • No labels