$wgGroupPermissions['user']['read'] = true; $wgGroupPermissions['*']['read'] = true; Release Checklist - Forge Wiki

Release Checklist

From Forge Wiki

Jump to: navigation, search

The "philosophy" behind a CamiTK release could be expressed as:

"Release Early, Release Often, but Release When (most important things are) Ready"


Release Schedule (principles)

Sprint #0

This is an exploratory sprint. It should last no more than a month. It allows the sprinters to cool down and think through all the next phase/release/project.

Sprints #1 to #5

Sprints #1 to #5 are about 1 months. They are code development sprints. A meeting takes place at the beginning of each sprint. It includes the sprint closure meeting of the previous sprint followed by the next sprint opening meeting.

At the end of sprint #5, CamiTK enters feature freeze (no more new stories are added to sprint #6)

Sprint #6

  • Sprint #6 is about 2 weeks. It is here to:
    • Increase external libraries versions, following our external libraries policy
    • write changelog and release notes
    • finalize the code development
    • soak testing
    • bug solving
    • memory leaks hunt. Use valkyrie to run valgrind and get a nicer output, see Valgrind imp configuration
  • The release preparation meeting takes place at the end of the Sprint #6. In this meeting the blocking bugs are identified and the resolving time line is decided. The release notes and changelog are presented at this meeting.

A blocking bugs can be:

    • missing/incomplete feature
    • application crashing bug
    • configuration/compilation/test errors

The precise list has to be established at the end of the release meeting.

Sprint #7

  • Sprint #7 is at most 2 weeks. It is here to:
    • Solve blocking bugs
    • Check cmake configuration and code compilation on CDash to reduce all warnings and errors. No configuration and compilation errors should remain in the opensource code, but there might still be some test errors or configuration/compilation warning.
    • Check compilation/installation from source package (Windows and Linux)
    • Format all source code into java convention source formatting, using artistic style

astyle --style=java -R *.cpp *.h

At the end of Sprint #7, the commit freeze is mandatory. The commit freeze is agreed on by email. After the commit freeze, no more .cpp, .h, .ui or .rc can me modified. CMakeLists.txt might still be updated to fix packaging bugs.

Just before the Sprint #8, find a date to celebrate the new release!

Sprint #8

  • Sprint #8 is a very short meeting (max 2 days) is here to perform all the packaging tasks:
    • merge the release branch to master and to develop
    • close and delete the release branch
    • increment version number in the develop branch. Modify the CamiTKVersion.cmake file of the current develop branch. It must always have an unreleased (future) version number. It can be later decided, depending on the modifications, to increase whether the minor or major version number.
    • create source code package, API archive, windows user package, developer package (development environment package). (For the source code package and windows user package: check sdk/cmake/modules/macros/camitk/packaging/CamiTKOpenSourcePackaging.cmake and follow the step described there)
    • upload all files to the forge
    • upload changelog to the website, update website
    • update the testing levels
    • publish release note to: RSS, partners (gmcao, timc, CAMI Labex, ECCAMI,...), camitk forum.
    • add the version number to bugzilla: go to the "Edit version" admin page, and add the version to each product.
    • Install new version in the big room machines
    • Compile basicmeca CEP and upload binaries on the internet (zip to uncompress in the CamiTK install directory or, even better provide an installer)
    • debian packaging is done separately, after the Sprint #8 (before Sprint #1 of the next release). Consider copyright for added files, etc...

Next Release Meeting

  • define the calendar (sprints, see above)
  • Check the incubator and select all parts that are elected for inclusion in the following release. This means the migration to the main OpenSource trunk is spread during the 8 following sprints.
  • Check and order sandbox. At the end of this process, all sandbox stories must be labelled :
    • "New" = added by anyone at anytime (not yet agreed/reviewed by the team), all new story should be labelled "New".
    • "[P1]" = reviewed story that has a high priority. It will be added to the current release if time allows.
    • "[P2]" = reviewed story that has a mid priority. It will be added to the current release if time allows, after having added high priority stories.
    • "[P3]" = a good idea that should be implemented one day. It also might be delayed to the next release (those are the least important to implant stories)
    • reviewed stories that have a strategically high priority should be added directly to the backlog (up to a limit covering 50% of the resources)
  • At least 50% and up to 75% of the resources attributed to the next release are allocated to the backlog.

CamiTK 4.1 Release Schedule

CamiTK 4.1 Release Schedule (tentative to be updated at the next Release Meeting). BOS = Beginning Of Sprint, EOS = End Of Sprint
Date Event
4 november 2016 BOS1 (development sprint #1)
1 december 2016 EOS1
1 december 2016 BOS2 (development sprint #2)
1 january 2017 EOS2
1 january 2017 Feature Freeze → branch release - BOS3 (finalize+test sprint)
1 february 2017 EOS3
1 february 2017 Release Critical - BOS4 (severe bug solving sprint)
15 february 2017 EOS4
15 february 2017 am Commit Freeze → create branch hotfix if needed - BOS5 (release sprint)
1 march 2017 am EOS5 - CamiTK 4.1 Release
3 march 2017 am Release meeting
xxx 2017 am
xxx 2017 am BOS0
Powered By FusionForge