> MAJOR version when you make incompatible API changes,MINOR version when 
you add functionality in a backwards-compatible manner

Although our changes are backwards compatible, they are only guaranteed to 
be backwards compatible for the previous two versions. Instead, semver says 
that code written for django 1.1 should run just fine on django 1.6.

> if it isn't earth-shattering, should be 1.10. Reasons to break things 
will pop up in due time (e.g. the death of python 2 in 2019). 

I'm also ok with django 1.10, though I also like incrementing the major 
version regularly as a way of saying "we don't plan on making 
earth-shattering changes". In retrospect, I think it would have been better 
if python made the backwards-incompatible changes slowly, with warnings, 
over the course of several releases instead of all at once. If we do ever 
make earth-shattering changes, I think it would be smart to use a whole new 
module and package name such as django2. That way you can easily have both 
installed at the same time.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/5fab23be-1411-4813-bfbe-ef85d0025452%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to