I'm going to agree with Tim, it's a good idea but it is hard to agree on
its impact without the specifics.
On 8 December 2014 at 15:04, Tim Graham wrote:
> 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 c
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 a
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:
On 12/07/2014 04:37 PM, Russell Keith-Magee wrote:
> For my money, the role of this policy change isn't to introduce
> instability into Django's process. The role is to give us permission to
> introduce features which we might not otherwise land (or might delay in
> landing) due to fears over wheth
On 12/07/2014 04:37 PM, Russell Keith-Magee wrote:
> 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 re
On Mon, Dec 8, 2014 at 7:49 AM, Michael Manfre wrote:
>
>
> On Sun, Dec 7, 2014 at 6:37 PM, Russell Keith-Magee <
> russ...@keith-magee.com> wrote:
>
>> * The corollary of this last point is that the release *before* a stable
>> release can't have any experimental/provisional features.
>>
>
> D
On Sun, Dec 7, 2014 at 6:37 PM, Russell Keith-Magee wrote:
> * The corollary of this last point is that the release *before* a stable
> release can't have any experimental/provisional features.
>
Does this mean that there should be no experimental/provisional features
in an LTS?
Regards,
Mich
On Sun, Dec 7, 2014 at 6:35 PM, Shai Berger 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
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 "experimen
On 12/06/2014 07:24 PM, Andrew Godwin wrote:
> My notes from the meeting say "experimental API language", so I may have
> taken an adjective too literally when I made this.
>
> Nevertheless, the key thing _I_ want to see is for us to commit to
> putting release notes out for some of Django's APIs
My notes from the meeting say "experimental API language", so I may have
taken an adjective too literally when I made this.
Nevertheless, the key thing _I_ want to see is for us to commit to putting
release notes out for some of Django's APIs that aren't necessarily
considered stable. The 1.7 data
On 6 déc. 2014, at 10:05, Carl Meyer wrote:
> As the DEP notes, our backwards-compatibility policy already includes a
> longstanding carve-out for anything documented within the "internals"
> section of the docs. We haven't made much use of this for documenting
> actual internal APIs (most of tha
Hi Andrew,
Thanks for putting together this proposal.
On 12/05/2014 09:32 PM, Andrew Godwin wrote:
> One of the results of discussions at Django Under The Hood was support
> for the idea of marking APIs "experimental" - that is, document them and
> include them in mainline Django releases, but aw
Hi everyone,
One of the results of discussions at Django Under The Hood was support for
the idea of marking APIs "experimental" - that is, document them and
include them in mainline Django releases, but away from the standard Django
deprecation cycle while still not hiding them under the "Internal
14 matches
Mail list logo
