Hi,

"It would also make it theoretically possible for the latest stable version 
to support the 
last LTS version from the same code tree".

Have you seen the latest changes to the deprecation policy? We hope we've 
done exactly that (having the latest version of Django support code that 
was written for the last LTS.)
https://docs.djangoproject.com/en/dev/internals/release-process/#deprecation-policy

Collin


On Thursday, November 12, 2015 at 7:48:28 AM UTC-5, Patryk Zawadzki wrote:
>
> Hello everyone, 
>
> I have spent quite a while thinking about this and am still not sure 
> what the best approach would be or even if there are enough benefits 
> to justify the change. 
>
> If you've ever worked with compiled code, you're probably familiar 
> with ABI versioning in dynamic libraries. This is somewhat similar. 
>
>
> The idea is to allow a project to specify that is _assumes_ Django to 
> behave like a particular version or release. It could do so by 
> specifying a TARGET_DJANGO_VERSION (better name needed) setting that 
> is a valid semantic version tuple. 
>
> Example: 
>
> TARGET_DJANGO_VERSION = (1, 8, 6) 
>
> New projects would start with the variable set to whatever Django 
> version was used to create them. If the variable is not set, Django 
> could raise an ImproperlyConfiguredError telling the user what to put 
> in the settings file or it could simply issue a warning and assume the 
> current version. 
>
>
> Now what that gives us: 
>
> * Django version Y could outright tell you that the project that 
> targets version X is not compatible and point you to the *relevant* 
> upgrade instructions (since we know both the old and the new version). 
>
> * 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). 
>
> * Django could introduce A/B feature switches that introduce 
> backwards-incompatible behaviour if a high-enough target version is 
> specified without breaking existing projects. It would also make it 
> theoretically possible for the latest stable version to support the 
> last LTS version from the same code tree (although it would probably 
> require an enormous legacy/compat module). 
>
>
> Is that something that was discussed in the past? Does it make any sense? 
>
> 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/26073e01-8517-4ee2-bdf1-c81c9503a88e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to