Development Process

Development Cycle

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. Iterations last three weeks, 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.

Issue Types

blocker - Issue must be fixed before an iteration can be completed (that is, blockers must be resolved before an iteration is tagged). Examples of blockers are bugs that make the system unusable or cause major loss of data.

critical - Issue must be fixed before a full release. Examples of critical issues are high-priority features or bugs which cause a major loss of functionality.

devSupport - Issue is related to developer experience. Examples include API improvements or developer tutorials.

duplicate - Issue is already described in another issue.

feature - Issue describes significant new functionality. Examples include new plug-ins or new configuration options to existing features.

enhancement - Issue is an improvement to an existing feature, which otherwise functions correctly. Examples include re-organizing GUI controls for usability purposes or improving performance. Note that enhancements are not subject to feature freeze (but are subject to code freeze)

wontfix - Issue exists, but will not be fixed for some reason. An example would be a bug in a feature that is planned for removal.