|
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
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.
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.
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.
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"
| A technical review of <link to actual documentation 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 |
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
ReleaseNotes.md
fileFluid.js
, in the framework codefluid
variable declaration at the top of each .js
filetests/manual-tests/framework/core/multipleVersions/index.html