Hi guys! As an external user of Django, relying on its stability, I'd like to comment.... In general, I think this is possibly a good improvement.. but possibly also a very dangerous one...
On Monday, December 8, 2014 12:38:18 AM UTC+1, Russell Keith-Magee wrote: > > > On Sun, Dec 7, 2014 at 6:35 PM, Shai Berger <sh...@platonix.com > <javascript:>> wrote: > >> I like the general idea of experimental API, although Carl and Aymeric's >> notes >> are important: If we do this, we need to very picky in its use, or else it >> just becomes an easy route to avoid committment. In particular, there >> should >> be a hard-and-fast rule that nothing should be made an "experimental API" >> if >> it can just be done outside of core. >> >> For the example given -- backend API -- I think that, again, Carl and >> Aymeric >> are right; the examples I have more in mind for this are user-facing ORM >> features like the expressions, or custom lookups. I think it might be >> better >> to let people play with them more, in a released version, before setting >> the >> APIs in concrete. >> >> With that in mind, I would also reconsider adding a silent warning when >> the >> features are used -- because, if they are for general use (as opposed to >> the >> use of, say, 3rd-party backend developers) then there's a significant >> use-case >> where the person who would use the API is not the person who configures >> the >> warnings on the CI. >> > > To my mind, the role of this new status is closer to "provisional", rather > than "experimental". It's a recognition of the fact that no matter how many > times we ask for pre-release testing, the first *real* test of any API is > when it sees real-world use. > What I would fear is not so much that experimentals/provisionals end up in other parts of Django itself: The Django team is well-disciplined and will understand its own release protocol :) I'm more worried that the application ecology starts suffering from symptoms of an experimental attitude in the Django project... This DEP would definitely have to be understood by the outside app-developer: For the stability of third-party apps, app maintainers should consider to put "don't use experimental APIs" in their contribution guidelines and make sure to go through the painful process of rejecting well-intended PRs relying on experimental components. Especially if it's decided not to raise Warnings when experimental modules are imported. For the projects and applications that do use experimentals, it would be nice to have a guarantee of a smooth API transition when the next Django ships. DEP states that APIs can change, but that it *shouldn't* do so. If stated that the API should not change, that causes for a much more significant guarantee, and sets the bar reasonably high for new experimental components. The amount of deprecations in Django in general is very high, and currently, supporting both South and db.migrations is quite hard. So adding more complexity to multi-version Django support does not sound very attractive to me and should be avoided at all costs. Some suggestions for the "experimental" definition / ruleset: - API has been thoroughly agreed and is not subject to change. - Only stability and performance is a questionable part that makes a feature experimental. - Internal parts of an experimental component are expected to change more than usual - Something does not get pulled out without a deprecation warning, even though it's experimental If experimental components will be allowed to change their APIs, I would definitely suggest a Warning to be raised so they're kept out of the app ecology. The relevant part of the DEP reads: Instead, an Experimental designation will allow APIs to be included in > Django and released without being beholden to the full deprecation cycle. > If you allow that to happen, then in essence, anything can be released and removed again. But there should be a clear intention when something is released, that it will be made permanent, right? DEP also states: Effort will be taken to communicate to users that the APIs in question are > not stable to avoid inadvertent use. > I don't think that's possible. If the feature is attractive, it will be used. RKM wrote: due to fears over whether the public-facing API is suitable for use. > This could be rephrased: Because some components do not get the exposure necessary for thorough testing through the availability and use of the beta releases, we need experimental components in the final releases. The goal is to get a broader test audience for *more rapid* releases and to have *faster* maturing of new features. Just be careful that this stuff doesn't end up where it's not supposed to, that's my main worry. Other than that, it's really easy to release django applications, and features not agreed to enter the django mainline have always been referred to release as an external component. This is possibly still the best way... Best, Benjamin -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9c6ced73-195f-4bc5-9f6c-8b8e6c7d6127%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
