Development workflow

The development of WikiToLearn will follow the following cycle, which lasts three weeks. The release-manager is Toma Luca <>, the git manager is Davide Valsecchi <>

Development (3 weeks)[edit | edit source]

Everything happens in the feature branches and when it's ready is merged in master. Each commit on master branch is uploaded on the staging machine reachable at

Feature freeze (6 days)[edit | edit source]

When the features chosen for the current development cycle are ready, they are merged in master and then the new release branch is created. The freeze period starts. A pre-production server loads automatically the commits on this branch. Only bugfix commits are allowed directly on WTL_x.y release branch. New development in other branches can continue without interruption, but nothing can be merged again in the WTL_x.y branch.

Release (1 day)[edit | edit source]

Each maintainer performs a checklist on the pre-production machine on Once green light is given by all the maintainers, the release happens and the branch WTL_x.y is tagged with a minor release index z like x.y.z. Every Unbreak It Now! task not completed BLOCKS the release.

Hotfix workflow[edit | edit source]

Bugfixs usually should not wait for new release to be published. They have to be committed directly on release branch. After tests on the pre-production server that loads automatically the commits, a minor release occurs with a new tag and the code goes to production.

All hotfix commits must be included then in the main development cycle. To do so cherry-pick them onto master.

Task tracking[edit | edit source]

Tasks are tracked on Phabricator. Each task reflects features on the Features Plan. The priority of every task has a precise meaning:

  • UNBREAK IT NOW: these task are extremely urgent and they must be resolved as hotfix if possible, directly on the current release branch. These tasks are security issues or big bugs.
  • HIGH : these tasks must be completed before the next release. They have to enter the freeze phase and they can't be delayed.
  • NORMAL: these tasks are normal work. If they are ready they can be merged in master, waiting for next release. If they are not completed they can be delayed to the next release, not merging in master, and remaining in their feature-branch.
  • LOW: these tasks can be inserted in wishlist for next release but they are likely to be delayed.
  • WISHLIST: these tasks are not inserted in the Features Plan.