Developer guide
The DMP Roadmap uses several branches to manage development work and ensure that the master branch always represents a stable version of the system.
- master: the latest stable version (not necessarily a marked release ... see releases below)
- development: the latest bug fixes and enhancements. These changes have not yet been released. This branch may or may not be stable.
- any other branches: represent bug fix and feature development that is not guaranteed to be stable
The DMP Roadmap team operates in a semi-agile manner and participates in a bi-weekly sprint cycle when possible. You can always see what we're working on in our current sprint by following our current sprint project. The team finalizes the work at the end of the sprint and merges it into the master branch.
These soft releases have been tested and are in a stable condition. They represent a subset of updates that will be included in the next upcoming release. Each release is represented by a git tag and the specific bug fixes and enhancements addressed by the release will be outlined in the release notes.
The team reserves the right to publish releases outside of the standard quarterly release window if necessary.
-
Milestones are assigned to multiple issues to group work being done that is related.
- Correlates to a feature.
- Major releases can defined by issues which are grouped via a label (ex: MVP)
- Issue tracker to define work at a more granular level, using labels and milestones to categorize issues. Issues are also used to report bugs and feature requests from users.
- The project board is used to organize and prioritize current development.
- A Pull request for a feature can be tied to issues automatically by adding
fixes DMPRoadmap/roadmap#[issue number]to your commit messages - After work is complete a tag/release is generated
- Release notes are created for each new release
 |
 |