See: Project roadmap
Doomsday's release cycle is designed around stable releases at fixed dates and a balance between feature work, productization, and bug fixing. This is intended to result in high-quality code and a decreasing known bug count in the long term.
There are three different kinds of releases: Unstable, Candidate, and Stable. For more information, see Build types.
The project's issue tracker exists as a bookkeeping and communication tool. Ideally, viewing the issues associated with a particular release should be enough to answer the question what has changed and what has been fixed in this version?
In practice, this means that all changes and fixes of high enough significance should be entered into the tracker in some way.
Especially bugs should be tracked very carefully and meticulously, so that end users and developers alike are on the same page about the status and history of known bugs.
The primary branch is called master. All builds are made from it automatically on a (usually) biweekly schedule by the automated build system. This means that all development in the master branch must be atomic enough so that the branch remains releasable at any given moment. Other branches should be used for working on new features until they are ready for merging into the master. Bug fixing should be done in the master branch so that the fixes are released immediately. (Contributors should take extra care of fixing bugs on the correct branch!)
Another important branch is the stable branch that is reserved for stable releases. It can be used for applying patches to the latest stable release.
We are using two kinds of work branches.