Handling feature flags
We need a decent definition how we should capsulate feature changes with a feature flag. The Goal for this adr is to have a final definition for all common cases. This adr should be used as a reference to implement a feature and get sure a MR can be merged and takes account to any of the defined points here.
- Everything that can be reached from external calls (routes, api definitions, schema, etc) needs to be hidden behind the flag.
- Code, which is changed or introduced by the new feature, should not be executed.
- Everything that is not possible to hide (new constants, new classes) needs to be annotated
Access to new constants or public functions cannot be prevented by the feature flag system. In this case you have to annotate the not available part with an @internal (flag:FEATURE_NEXT_1128) comment
const NEW_FEATURE_CONST = true;
New Routes have to return the NotFoundHttpException if the flag is not active.
Don't annotate planned deprecations with the official
@deprecatedannotation, to avoid making deprecations public before the feature is released. (Everything behind a feature flag is unstable and can be removed and changed at any time). Instead, use the annotation
@feature-deprecated (flag:FEATURE_NEXT_1128). This annotation will be replaced with the real
@deprecatedannotation when the feature flag will be removed.