# Implementing a Formal Experimental API for Django **URL:** \ **Category:** Django Internals\ **Created:** [June 3, 2026, 6:52am UTC](https://forum.djangoproject.com/t/implementing-a-formal-experimental-api-for-django/45217 "2026-06-03T06:52:29Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![CodenameTim](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/codenametim/32/31507_2.png) [@CodenameTim](https://forum.djangoproject.com/u/CodenameTim)\ **Post date:** [May 22, 2026, 1:21pm UTC](https://forum.djangoproject.com/t/implementing-a-formal-experimental-api-for-django/45217/2 "2026-05-22T13:21:49Z")
Thanks for kicking this off Praful! > [@GSoC 2026: Implementing a Formal Experimental API Framework for Django Core](https://forum.djangoproject.com/t/gsoc-2026-implementing-a-formal-experimental-api-framework-for-django-core/45158/1): > > How should we decide when an experiment ends? The current idea in the proposal is a flexible Evaluation Period where features are reviewed after each minor release, rather than setting a strict deadline. What should be the deciding factors for a feature to be promoted to stable or purged to prevent experimental bloat? I don’t think we’ll arrive at a standard set of rules for every possible situation. I suspect each feature will have its own reasons for being added in an experimental state, and therefore it would have its own reasons for when it would exit experimental. I think it’s fair for the community to ask for a feature to include why something qualifies as experimental, what are the criteria that needs to be met for it to be made stable and what are the criteria that needs to be met for it to be removed entirely. One thing that could help those discussions along are guidelines for what are reasonable justifications for experiments and what are some example/plausible exit criteria. --- _[View the full topic](https://forum.djangoproject.com/t/implementing-a-formal-experimental-api-for-django/45217)._