OpenMCT is developed on a regular cycle:
An iteration represents a minor milestone. Iterations are considered beta versions: At the end of an iteration, the code base should be reasonably stable, but may contain major issues. Iteration duration is decided ahead of time; typically an iteration lasts three to six weeks, depending on available developers, but may be extended as needed to resolve blockers. A new iteration will typically start immediately after the end of a previous iteration, but may sometimes be delayed in order to support other activities.
A release represents a major milestone. Releases are expected to be stable and free of critical issues. A release is completed every four iterations. Typically the third and especially fourth iteration will be focused on or devoted entirely to bug fixing, in order to ensure the stability of releases.
Important dates within an iteration:
Feature freeze is one week before the scheduled end of an iteration, typically midnight on a Friday. Code for significant new functionality should not be pushed to the master branch after this deadline in order to ensure sufficient time for testing. Enhancements, which are improvements of existing functionality, may still be checked in.
Code freeze occurs two working days after feature freeze, or three days before the end of the iteration. No new code should be pushed to the master branch after this deadline, except to resolve critical issues or blockers.
Completion of an iteration occurs on its last day, which is normally a Friday. During the intervening time between code freeze and completion, significant testing is performed, along with fixes for critical issues or blockers. If necessary, the completion of an iteration or release may be delayed in order to address such issues. The subsequent iteration will either be postponed or shortened to accommodate such delays.
Iterations are listed in the issue tracker as milestones; these include the planned date of completion. Note, particularly for future iterations, that these dates may change, as described above.
Iterations and releases are tagged by their version number. A release's version is 1.x.0, where x is the number of that release release; for instance, Release 7 is version 1.7.0 and tagged "v1.7.0". Iterations are given beta suffixes for purposes of version numbering; for instance, Release 7 Iteration 2 is version 1.7b2 and tagged "v1.7b2". (Version numbers such as 2.x+ are reserved for fundamental changes to the platform, should they occur, and are not anticipated as part of the development process at this time.)
Patches to releases may sometimes be necessary. In order to ensure consistent version numbering, these should increment the minor version number of the release (i.e., to 1.7.1 from 1.7.0) and be tagged accordingly. This ensures that tags remain stable and that user-visible version information remains unambiguous.
Starting at the end of Release 8 Iteration 1, development process changed from a regular three-week iteration cycle to a looser "when appropriate" iteration cycle, to match changes in team size.
Starting at the end of Release 8 Iteration 3, code review requirements and second-party issue verification have been suspended due to further reductions in team size.
Any given issue may have multiple labels, or no labels. For instance a performance issue may also be a blocker, if the performance problems are so severe that essential functionality becomes impractical to use.
Last edited by VWoeltjen,