We should introduce officially something like “preview technology” for some new feature that are stable, but that can change (interface, integration, …) are not stable.
Like this we don’t reinvent the wheel each time we introduce something bleeding edge So we also have the responsability to make preview tech stable in the next few release. A bit like a inversed “deprecated” tag. So a preview tech can have an announcement in a release and release + N should make this tech a stable one.
Following the discussion in “Integrating domain specific langages (DSLs) into fusion”.
Something usually called a “feature switch”, and yes, we already decided to use that in case it makes sense. We even have the feature switch for the logging, disabled for ages…
It’s not really about enabling or not the feature. More to make it clear, that the current feature is not stable code wise and should not be extended currently. Having a feature switch per feature, can be one level lower, like “Experimental feature”.
What we have an API for feature switching ??? (continous learning …)
There’s no standardized way for feature switches, currently there’s this one kinda used as a feature switch https://github.com/neos/neos-development-collection/blob/master/Neos.Neos/Configuration/Settings.yaml#L529
I guess it makes sense to group such settings together, although not doing it makes it easier to roll out since you wouldn’t be left over with deprecated feature switches in your configuration.