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)
- contributions: the latest contributions from external contributors. Bug fixes and enhancements in this branch have not yet been released. This branch may or may not be stable.
- development: the latest bug fixes and enhancements that the project team is working on. These changes have not yet been released. This branch may or may not be stable.
- any other branches: represent development work that is likely unstable
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.
- Pull request for a feature can be tied to issues automatically with “fixes” notation
- After work is complete, perform a tag/release.
- Release notes need to be created for each release
 |
 |