This is just a proposal I have for discussion and for which I would like more feedback.
The general idea is that we could start shipping experimental features or API in otherwise stable releases:
- Experimental parts of the codebase could be mark with an
@expirementalflag (or something similar) and/or be disabled by default, requiring developers to opt-in into using it by modifying their YML config.
- Our SEMVER commitments would not apply to experimental APIs. Those APIs could be change or removed completely in a future miner releases.
- Experimental features would be announced in a dedicated section of the changelogs. This sections would also be used to notify users of experimental API that have changes or been removed.
- Features/API would only be in the “experimental” stage for a short time. They either get remove from Core or become officially supported within a the time frame of one minor release or two. (The idea here is to avoid a scenario where we ended up with dozens of long live experimental APIs in our codebase)
What’s the rational for this
Because module like framework or asset are officially supported, we’re understandably wary about adding new API to them because we’re on the hook for supporting these API long term. This limits our ability to quickly iterate over proposed changes and require us to spend a lot of time upfront validating that a new feature/API has value before shipping it.
This slows down core development considerably.
Works on unsupported/not-supported-yet module in comparison is much more fast pace and allows us much more leeway for mistakes and for changing our minds after the fact.
A good example of this approach is browser vendors that will ship experimental or incomplete features in otherwise stable releases. This allows real life users to help test and refine the feature.
Example of features that could be good example to be shipped on a “experimental” basis
- Add a trait to bootstrap ViewableData into react component
- Allow file variant with different extensions
- Smarter search for gridfield
- If you’re developing Silverstripe CMS projects, would you be keen to try out experimental features? In a sandbox environment? In production?
- As core developer, would you be keen to get features shipped this way? Do you foresee any potential problems?
- Does shipping “experimental” code in a stable release create potential communication problems or confusion?
- How would we decide what features are good candidate to be shipped as experiments?
- How would we collect results and data from experimental features?
- How would we decide what happens with experimental code in the long run?
- How do we mark a feature as experimental?