====== Project roadmap ======


See: [[http://tracker.dengine.net/projects/deng/roadmap|Project roadmap]]


===== Conventions =====


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.

  *  **Stable releases at fixed dates** is important because otherwise there is a high likelihood of stable releases being postponed. The ever-present "snowball effect" easily causes feature work to expand into unplanned areas and directions, and this tendency must be consciously kept in check. The objective is to make high-quality stable releases at a regular frequency.
  *  **Feature work** is what drives the project forward. This is the exciting stuff that motivates developers to work on the project. However, during this type of work it is difficult to do general bug fixing in other parts of the code. To keep the master branch from breaking, this type of work should generally occur in separate work branches.
  *  **Productization** is when the master branch is merged into the stable branch, and the stable branch is then cleaned up to be suitable for use by everyone. Usually this involves a lot of polishing, verifying edge cases, and generally tying up all the loose ends after the work branches have been merged.
  *  **Bug fixing** is a crucial step where reported and other known bugs are addressed. During the bug fixing phase, bugs are evaluated, and fixed if possible. Bugs may also be scheduled for upcoming unstable phases, where the fixing will occur as a by-product of some larger change or improvement.


===== Release types =====


There are three different kinds of releases: Unstable, Candidate, and Stable. For more information, see [[automated_build_system#Build_types|Build types]].


===== Tracking =====


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.


===== Branches =====


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.