To ensure a good experience for developers or advanced users and to keep the work for the core team on a manageable scale, it is important to know what guarantees are given for different parts of the MITK Git repository.
- developers to make a qualified decision if they want to play it safe, go bleeding edge (and we mean bleeding, so you may get cut) or something in between.
- contributors (internal and external) to understand the definitions of done (DODs) for contributions.
The code guarantees are grouped into quality levels (Q0-Q3) which are used to easily reference and communicate quality promises and requirements in our release concept.
In the following we explain the different quality levels, their intended purpose, given guarantees and quality measures. This helps developers and power users to pick the right starting point for their own builds or developments.
Quality levels have a repository scope. A branch/tag in the repository always has a certain quality level (e.g. origin/develop is Q1). The guarantees given in a quality level may only hold for a part of the source tree (e.g. in origin/develop the whole source tree compiles, but only a part of the source tree gets active code reviews). That's why quality guarantees have a source scope; if no source scope is specified, the global scope is implied.
Nearly no guarantees at all! This is ongoing work in progress. You should only build or base your own work on this quality level if you really know what you are doing (e.g. you have talked to the branch owner and his given guarantees are sufficient or you are working on a closely related topic). Developers are requested to create compilable commits, but even this is not obligatory.
So, be welcomed to the wild west and don’t say we haven’t warned you! Yee haw...
- Branches are always associated with a task, to follow the process and its history (even if the branch is merged and gone). Therefore, all branch names obey our naming convention that includes the corresponding task number. For details, see Git Branching Model.
- feature and bugfix branches
- hotfix branches
- support branches
The certainly compilable, CI-monitored, bleeding edge; no more, no less. You can be quite sure that it compiles but you should check the CI build status. The CI also runs unit tests and experienced developers reviewed changes to the critical or important parts of the code base.
In addition to the Q0 guarantees:
- Code certainly compiles on all tier 1 platforms.
- Continuous and nightly (clean build) unit tests.
- If the dashboard is not green on tier 1 for any reason, it will be promptly fixed.
- Commits that touch core or other important parts of the source tree are reviewed by MITK developers. The review ensures that all guarantees are fulfilled and comprises an actual code review. The source scope is defined by:
- release branches
For developers that are not depending on the GUI parts of MITK, it is a save pick as a green dashboard is guaranteed. All those who want to use the Workbench or other GUI applications should be aware, that undetected errors in the GUI might have slipped in as only fundamental smoke tests have been made and extensive GUI checklist testing is not guaranteed at this level. So if you make GUI developments, it is a good practice to first check the GUI parts relevant for you, before starting your own developments. Otherwise it becomes hard for you to distinct, if issues are introduced by your changes or where already present before your first commit.
In addition to the guarantees of Q0 and Q1:
- All changes are mentioned in the Changelog.
- Code compiles also on all tier 2 platforms.
- Passed simple smoke tests for all tier 1 platforms
- Inofficial snapshots installers are available
- The MITK Workbench starts and closes properly
Recommended for usage if you want the highest quality, e.g. for a production environment. As a trade of, it does not provide the latest features, additions and improvements.
In addition to the guarantees of Q0, Q1, and Q2:
- Passed manual checklist testing (source scope TBD).
- Documentation is up-to-date. The source scope is defined by:
- All associated web resources are up-to-date and official release installers are available on our website.
- Commits in origin/master tagged as official releases