This comment has been minimized.

this is risky; I think there's a good number of apps that have reopened didTransition (and called _super) to hook into this event. Perhaps the right answer is branching to finalizeTransition within didTransition if the feature flag is enabled? Does didTransition need to be renamed at all?

this is risky; I think there's a good number of apps that have reopened didTransition (and called _super) to hook into this event. Perhaps the right answer is branching to finalizeTransition within didTransition if the feature flag is enabled? Does didTransition need to be renamed at all?

This comment has been minimized.

@huafu - They are tracked in features.json (with descriptions in FEATURES.md) in the root of the main repo. Once a feature is shipped in a release version, the feature flags are removed, and the feature is simply part of the main build.

@huafu - They are tracked in features.json (with descriptions in FEATURES.md) in the root of the main repo. Once a feature is shipped in a release version, the feature flags are removed, and the feature is simply part of the main build.

This comment has been minimized.

Basically no. Once a feature has been enabled and published in the release version (a final non-beta release) it is considered public API and is then bound by the same SemVer requirements as any other piece of the code base.

Up until it is enabled and released, it can be removed (and this has happened once or twice).

Basically no. Once a feature has been enabled and published in the release version (a final non-beta release) it is considered public API and is then bound by the same SemVer requirements as any other piece of the code base.

Up until it is enabled and released, it can be removed (and this has happened once or twice).

Basically no. Once a feature has been enabled and published in the release version (a final non-beta release) it is considered public API and is then bound by the same SemVer requirements as any other piece of the code base.
Up until it is enabled and released, it can be removed (and this has happened once or twice).

Basically no. Once a feature has been enabled and published in the release version (a final non-beta release) it is considered public API and is then bound by the same SemVer requirements as any other piece of the code base.
Up until it is enabled and released, it can be removed (and this has happened once or twice).