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 real-world use. > > In some respects, it a return to the pre-1.0 status of Django APIs, > where we would endeavour to maintain backwards compatibility if at all > possible, but we would be willing to break an API if it was in the best > interests of future use. As an example of the sorts of things that got > changed see: > > https://code.djangoproject.com/wiki/BackwardsIncompatibleChanges > > The difference here is that we're doing it for a specific API or new > feature, not for the entire API. > > I agree that "experimental" status shouldn't be used as a way to avoid > commitment. IMHO, the "rules of use" are something like this: > > * It can only be used for major feature APIs. If a feature doesn't > warrant a significant mention in the release notes, then it's either an > internal API, or a minor feature that we can live with being locked down. > > * There is a strict timeline - if a feature is provisional/experimental > in vX, then it should automatically be final in vX+1, unless enough > changes are made to the API that warrant another > provisional/experimental version cycle. However, at each release, the > intention should be to lock down all provisional APIs in the previous > release if at all possible. > > * The corollary of this last point is that the release *before* a > stable release can't have any experimental/provisional features. > > * Even though we have the escape hatch, we only use if if we have to. A > rapid-deprecation backwards compatible path is preferable to a > fundamental backwards incompatible change. > > 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 whether the public-facing API is suitable for > use. > > Russ %-)
Thanks Russ (and Shai), this is very helpful. For one thing, it's good to clarify that we're _not_ talking about the database backends API here -- I think that's a unique case where "internal but documented" (a status we already have) is a better fit than any of "experimental" or "unstable" or "provisional". I agree that for big new public-facing features, "internal but documented" doesn't fit as well. And secondly, if we are going to do this, I think "provisional" is a much better choice of term than either "experimental" or "unstable". Nonetheless, I am -1 on this DEP. I certainly see the initial attraction of the idea from the core developer standpoint, but I don't think in practice it helps anyone. Nobody (to a reasonable first approximation) will wait an entire release cycle to use an awesome new feature like migrations or ORM expressions just because we've labeled the API provisional. So in effect, all we've done by introducing the provisional label is add needless complexity to our policies and given ourselves a reason to break our users' code more cavalierly than we'd have otherwise done. Instead, I think we should continue to do exactly as we have done in the past: add new features, make them as good as we possibly can with the testing that we get pre-release (and frankly, though it took a few RCs, we got a _lot_ of user testing of migrations before they were ever in a final release), and then if major issues crop up after release, do our best to fix them in as backwards-compatible a way as we can manage. It's not like our backwards-compatibility policy is an unbreakable straitjacket. When we have no choice in order to fix a critical issue, we have broken backwards-compatibility without a deprecation path before, and I'm sure we will do it again. But that choice should remain an absolute last resort; usually a deprecation path is possible. For any feature, whether new or old, we should stick to our backwards-compatibility policy as closely as we can, and break it only when we have no other reasonable choice. I don't see this "provisional" label adding anything new or useful to that decision-making process. Carl -- 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/5484F425.4020104%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
