Experimental APIs - #114

While I'd love to see the first_name and last_name go, I'm not clear enough on how the experimental zone will interact with migrations to enable this cleanly.

Would we have new migrations in the experimental area that we opt-in to by adding a suitable entry in INSTALLED_APPS? If so, what would the process be for moving the migrations into stable once the experiment is successful? How do we handle removing migrations if the experiment is unsuccessful?

Very good questions Lily! I suggested this area as an example for us to ground the conversation of the flags in a real problem which the community would like to see changed, but very likely impossible to change via the current methods (I could be wrong).

While the migrations would be tricky, it enables to propose a fresh default User model to work from (at least for new projects).

More broadly this is something we (myself & Praful) can experiment with once we something of flags up and running.

I don't draw this same conclusion when I read the ticket. I think it stalled because of the complexity of "juggling so many database-specific flags", which is the nature of a cross-database abstraction given the complexity of the function we are talking about. I don't think this example backs up the "why" point here.

Would multi-column primary keys be a more relevant example for this?

Yes!

Well, it has a different effect than the original example because it's something that we did merge without putting it under an experimental namespace and without the need for shipping a lot of incremental deprecations for design changes. So its success doesn't really demonstrate the need for a change.

Sure, but I meant it more as could have things gone better with a less restrictive support policy for it? Better being subjective across a number of facets (communication, documentation clarity, development, etc)

One broad topic I come back to is with this idea is how this works with the current release cadences and how the community installs Django.

Currently Django has 3 release types. Bugfix, Feature & Series releases (from DEP 19). DEP 20 changes this and effective drops this down to 2 types (Feature & Bugfix).

Bugfix releases are shipped monthly. This is the current minimum time to ship something as I understand it, but these bugfixes are specifically backported to frozen feature branches.

I think therefore there is only one way for developers to test these experimental features quickly inside Django and that is installing Django from the main branch (or a slightly delayed main branch). - which is not a bad thing, ideally more folks would test/use Django against main (https://noumenal.es/posts/running-django-main/O2x/)

This means only those installing from main will get experimental features iteratively (and therefore quickly)

Worth noting the above is my current thoughts. I'm working through how this affects the project overall and being useful to the community

The other possible path here is that we choose to start using python package extras to generate releases with the experimental code included. This would mean that we wouldn't be limited to having code within Django core that appears in a final Django package.

I generally think that we need to investigate the release process and what the Fellows would think to additional work added to the release process or more additional releases being added to the process.

I think therefore there is only one way for developers to test these experimental features quickly inside Django and that is installing Django from the main branch (or a slightly delayed main branch). - which is not a bad thing, ideally more folks would test/use Django against main

Recommending people to use main for production applications is probably not a good idea. Mistakes still happen. For a project that hangs its hat on stability, recommending people use main in production seems like contradiction. Sure, there's room to have "versions" of main that are more reliable or have a high degree of reliability, but that doesn't exist in our process today so it likely shouldn't be included here.

Low: I think the term "experimental" needs clarification. I suspect folks have different opinions on it. For me, I imagine it's something that's fairly likely to be merged in, but there's some hesitancy. It's basically just a new stage of integrating a feature, but in this case we know we need to go slower with this feature than normal.

I'm drawn to multi-column primary keys as something that may have benefited from this. It's implemented, but not fully. Would it be helpful to be able to change the public API for another release without deprecations?

I think this needs rethinking. Bug reports should always go through Trac. Being able to note the experiment or feature in there would be helpful.

I think the feedback portion is a good idea, but we should provide a bit more structure for someone. If we have an experiment, there was a reason for it. That's the spot that we particularly want feedback on. How do we make that easier for everyone?