- Bug coordinators and developers want to open backporting tasks (to milestone-proposed, to stable branches) as part of a bug story
- Release management needs to track what made it to a given milestone and/or final release and point release
Tasks should have two additional properties:
- branch: the branch the task is supposed to land in (for projects with a code repository attached to them). Defaults to master.
- milestone: the first milestone or version where the fix landed.
Branch is selected by the user as part of the task creation (defaults to master). For autocreated tasks, it's set based on the change's target branch.
Release is set as part of the release process: when a milestone-proposed branch is cut, we collect all master-landed fixes without a release set and mark them as released in the corresponding milestone. Then when the milestone is tagged, we collect all the milestone-proposed-landed fixes (if any) and mark them as released in the corresponding milestone as well.
- branches: list of branches available (master, stable/havana...). Maps n:n to projects through a mapping table
- cycles: group of milestones (icehouse). Maps n:n to projects through a mapping table
- milestones: list of milestones available (icehouse-1, icehouse-2, icehouse-rc1...). Each belongs to a cycle
- tasks should have two new columns:
- branch_id referencing a row from branches (defaults to master)
- milestone_id referencing a milestone (or null if milestone not released yet)
Potential additional development
- If we special-case feature stories, those shall only have "master" tasks since we don't backport features.
- To view the list of stories/tasks shipped in a given release, we can have view targeting the cycle rather than each separate milestone.
- Release tools to create and delete the temporary milestone-proposed branch (a few days before milestone cuts)
- Release tools to pick up master-landed fixes (and milestone-proposed fixes) and set milestone for them on milestone cut weeks