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 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
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
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
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:
"Tech review of <page> docs"
where <page> may be
- <component> API
- <component> Tutorial
- a framework section, such as Events, Subcomponent, or Renderer
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.)
- 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
- the version string in
Fluid.js, in the framework code
- the version number in the
fluid variable declaration at the top of each
back to top