Add experimental features policy

[mtrezza]

New Feature / Enhancement Checklist

• [x] I am not disclosing a vulnerability.
• [x] I am not just asking a question.
• [x] I have searched through existing issues.

Current Limitation

Parse Server does not have a concept for "experimental" features. In the past, some features were in some way or another indicated as being experimental. That practice has been abandoned with the reform of Parse Platform's code management in 2020/2021.

The purpose of that reform was to introduce more predictability and transparency for developers, which was one of the top concerns voiced within the developer community at that time. Some results of that reform were policies like fixed release cycles with pre-releases, deprecation policy to avoid braking changes and clearer pull request classification and changelog semantics.

In that context, the loose declaration of features as "experimental" brought several challenges in the past:

• a) No definition: There was no definition of what an "experimental feature" was. How long it will be available, whether it may be removed again, whether people should rely on it becoming official, how feedback is evaluated, how long a feature would be experimental, what exactly was to test about the feature and why was it still experimental.
• b) Unclear expectation: A developer did not know whether an experimental feature was excluded from any policies that apply to the rest of the codebase, e.g whether breaking changes could happen unannounced at any time. In the past, in practice, breaking changes in experimental features would not trigger a major version increment, but looking at the currently existing experimental features, an unannounced breaking change would likely negatively affect many production deployments.
• c) No containment strategy: Every change to the codebase has a potential implication for the stability and security of the whole codebase. It was not clear for contributors and reviewers, what changes are allowed and to what degree and how an experimental feature must be "containerized" by code to mitigate the risk for stable code which developers need to rely on.
• d) No follow-up: In the majority of cases, experimental features were flagged as experimental for years and presumably widely used, even though one could not officially rely on them. In some cases, general bug fixes were made in the "experimental" code path while the "stable" code path became more and more neglected. That caused confusion for developers. It shifted attention away from stable code to experimental code, effective creating two separate maintenance scopes, which to this day complicates overall code maintenance.
• e) Unclear strategy: It is unclear when and how an experimental feature should be prioritized for being added to a Parse client SDK. Given resource limitations, this should be evaluated in the context of an overall introduction plan for that feature. Since an experimental feature naturally has a higher code change frequency, breaking changes are more likely if an experimental feature spans multiple products.

Feature / Enhancement Description

Evaluate a potential introduction of experimental features through a comprehensive policy that addresses the issues experienced in the past.

Example Use Case

• custom-routes - still experimental though presumably widely in use
• idempotency-enforcement - still experimental though by now tested thoroughly in various deployments
• pages - still experimental though presumably widely in use as it's a required feature to fully localize Parse Server
• direct access - not experimental anymore, was experimental for a long time, so that within the community it was often suggested to switch on the feature to fix various issues, often without mentioning associated risks

Alternatives / Workarounds

Status quo: expect a feature to be - in best conscience - production ready for it to be merged. That shifts more responsibility for testing and quality to the original contributor to get their PR merged.

[parse-github-assistant[bot]]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[dblythy]

Thanks for the detailed documentation here - I guess the concern is certain newer features might be unstable and have impacts not covered by code coverage, and a lot of those bugs won't be caught until it's rolled out. Maybe that's expected with new features though that they are going to become more stable though maturity.

[mtrezza]

I think if we can come up with a policy that works, we can add experimental features to the codebase. It's just that the examples above show that an "experimental" stamp is not a blank check to get something merged. There needs to be a defined barrier of entry for new code (currently that is "production ready"), clarity for developers and a plan how and when to bring a feature out of experimental state.

[dblythy]

Regardless of whether a feature is "experimental" or not, open source depends on users finding bugs and vulnerabilities and then reporting and/or contributing back to the project. My expectation would be that an "experimental" tag would mean that bugs are more likely to occur and the feature needs community support / polish to move into a ready state.

[mtrezza]

I don't think anyone is doubting that. The point is that the challenges above are very real and need to be addressed before we add any experimental feature.

Please feel free to make a proposal for each of the points to kickstart the discussion.