I am skeptical like Carl, but it seems to me the time to introduce and discuss this DEP is when there is an actual feature that we think could benefit from this policy so we don't have to talk in hypotheticals.
On Monday, December 8, 2014 7:00:44 AM UTC-5, benjaoming wrote: > > 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 <[email protected]> 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 [email protected]. To post to this group, send email to [email protected]. 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/938dd835-3678-483e-ab30-0bfeda9fd3db%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
