Refactor releases to be anticipatory, not just post hoc
| Project: | Project |
| Version: | 6.x-1.x-dev |
| Component: | Issues |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Right now it looks like the concept of release is just a post hoc grouping of completed issues.
It would be nice if releases could be anticipatory, meaning I could use them as planning points.
For example:
Current method: Work work work on issues filed for version 1.2 and prior. Oooh, now I've done "enough." Create 1.3 release to reflect "enough" progress.
Proposed method: Have 14 issues against 1.2 and prior versions. 6 are "blockers" for 1.3. Go ahead and create 1.3 release now as a placeholder or milestone (per #605512: Convert "API version" to generic milestones), and assign those 6 issues as prereqs for completing 1.3. Work work work until all 6 issues are completed, then set 1.3 to finished.
Note that I'm not suggesting devolution into waterfall-style project management. But I do think milestones have merit for planning purposes.