2015-11-12 17:40 GMT+01:00 Carl Meyer <[email protected]>: > On 11/12/2015 05:48 AM, Patryk Zawadzki wrote: >> * Setting the target version to a higher value could turn deprecation >> warnings to exceptions for all features deprecated in the target >> version and earlier (which could make future-proofing your code >> easier). > You're proposing this would only activate if your TARGET_DJANGO_VERSION > is higher than your actual Django version? I'm not sure how this feature > is even possible as you've described it, since if you have Django 1.8 > installed and you set TARGET_DJANGO_VERSION to (1, 9, 0), that doesn't > magically give Django 1.8 knowledge of future deprecations! Perhaps I'm > misunderstanding.
Consider Django version 1.9 that also happens to support API versions 1.7 and 1.8 and an application that originally targetted 1.7. I could leave my target API at 1.7 and get the app to work. This requires minimum resources. I would assume during normal operation deprecations introduced in 1.8 and later would not show up since I'm explicitly targetting 1.7. I could also bump my target API to 1.8 and get some more deprecation warnings for things deprecated in 1.8 (but not in 1.9). At this point things deprecated since 1.7 should stop working so I can make sure that I am actually targetting the "intended" APIs of 1.8. I could finally go all the way up to 1.9 and possibly get different behaviour when calling the same functions I did while targetting 1.8. See below for discussion. > Plus, it's not hard to use filterwarnings to turn all deprecation > warnings into exceptions (I often do this on my projects, at least for > the test suite). Perhaps this is a technique we should recommend and > demonstrate somewhere in our upgrade docs? Yes, this is how I imagine this to work. Specifying the target could among other things configure which warnings are ignored and which are explicitly turned into errors. >> * Django could introduce A/B feature switches that introduce >> backwards-incompatible behaviour if a high-enough target version is >> specified without breaking existing projects. > This is tempting at first blush, because it allows us to claim that > you've opted in to whatever backwards-incompatible changes we feel like > making by bumping your TARGET_DJANGO_VERSION. I think this is false, > though. You don't know what all you're opting into by bumping your > TARGET_DJANGO_VERSION unless you carefully read the release notes. > (Unlike other opt-ins which typically involve changing the use of > specific APIs in your code.) So how is it any different from us claiming > that you've already "opted in" to backwards incompatible changes simply > by upgrading Django? (In practice, we _do_ claim this already, but we > try to minimize such changes.) > > I guess the idea is that you could first upgrade Django but leave your > TARGET_DJANGO_VERSION alone, and nothing would break, and then you could > at some point bump up your TARGET_DJANGO_VERSION when you're ready to > deal with the breaking changes? In the end I'm not sure that's any > better than today's story, which is just "upgrade Django when you're > ready to deal with the breaking changes." Yes, you could upgrade Django safely at least X times before having to touch any code. You could also target a major version like 2.5 and not experience potentially incompatible but more secure change to default settings introduced in its point release, 2.5.7, while allowing new projects to benefit from that change. Cheers, -- Patryk Zawadzki I solve problems. -- 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/CANw2pUF3CsY0%2B_q_ABk2bfHeHzF3HVF9m39iYXapM0ox7Te%2BxQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
