QUIP 14 | The Module Life-Cycle
QUIP: | 14 |
---|---|
Title: | The Module Life-Cycle |
Version: | 863be0e11aaabef0a9e0a9459c7b05a3d9085d74 |
Last-Modified: | 2021-07-15 |
Author: | Edward Welbourne |
Status: | Active |
Type: | Process |
Created: | 2018-09-14 |
Post-History: | https://lists.qt-project.org/pipermail/development/2018-November/034344.html |
Contents
The Module Life-Cycle
New modules are added to Qt from time to time. These typically start out as playground projects, migrate to technical preview components of the primary Qt checkout and eventually mature into maintained modules.
This QUIP describes the prerequisites for a module to make each of the transitions in that life-cycle. At each step, those proposing the transition should post to the Qt project's developer mailing list making the case that the module satisfies the prerequisites and requesting that the module make the transition.
Acceptance as a Playground Project
For a module to be accepted into the Qt project's playground we require
- A defined scope for the project,
- A responsible person/maintainer and
- A commitment to follow Qt coding guidelines and project structure.
TODO: what happens when it's accepted ? Where is the playground ?
Entering Technical Preview
Here are the criteria for a module to be added to the main Qt project as technical preview modules (first proposed in [0]):
- The module solves a problem our users have - It either implements new and so far non existent functionality - Or it solves an existing problem in a new and better way (and is intended to replace the old functionality over time)
- The module builds inside the Qt build system on all platforms
- Compilation could be disabled on some platforms, but is not allowed to break any platform we support
- The module is CI controlled
- There is a decent set of automated tests covering the main functionality and most of the API of the module - The tests pass on all platforms where the module is supported
- APIs have been reviewed, and we are reasonably satisfied with them (we've done larger changes to APIs after TPs before)
- Architecture makes sense
- It follows the Qt coding style and conventions
- Implementation has been checked for sanity - It's ok to have parts that are flagged as needing further work (those have to be fixed before moving from TP to supported state)
A module accepted into technical preview shall be added to one of the Qt project's released supermodules, with status set to preview in its section of the supermodule's .gitmodules file. A technical preview module makes no promise of source compatibility or binary compatibility between versions.
Becoming a Maintained Module
TODO: what are the prerequisites for this ?
Once a module is accepted as a maintained module, its entry in its supermodule's .gitignore file is updated to a status that reflects its role. Maintained modules are part of regular Qt releases and are required to live up to the standard source- and binary-compatibility promises that the Qt project makes to its users.
References
[0] | Post by Lars Knoll on qtremoteobjects as Tech Preview https://lists.qt-project.org/pipermail/development/2017-January/028313.html |