#23015 closed Bug (fixed)
Don't announce Django 2.0 as a backwards-incompatible release
| Reported by: | Aymeric Augustin | Owned by: | Tim Graham |
|---|---|---|---|
| Component: | Documentation | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Over the last years, the consensus has slowly shitfed toward making the 1.9 -> 2.0 transition not more disruptive than other 1.x -> 1.y transitions (where y = x + 1).
The first section of https://docs.djangoproject.com/en/dev/internals/release-process/ should be update to reflect this.
Change History (9)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
We should redefine "major release" in docs/internals/release-process.txt. Everyone considers Django 1.x, 1.y, etc. major releases.
comment:3 by , 10 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
| Triage Stage: | Unreviewed → Accepted |
comment:5 by , 10 years ago
I think the idea here is good. But what happens in the future if some serious backward-incompatible changes need to land - there would be no way to indicate with version numbers that big shift. Or, is the idea that no such serious changes will ever occur all at once (similar to now, where there's 2 major releases to slowly deprecate functionality)?
comment:6 by , 10 years ago
Current consensus is that no such changes will occur in the foreseeable future. If such changes are needed at some point, then we'll cross that bridge when the time comes.
comment:8 by , 10 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Related: docs/internals/howto-release-django.txt and docs/releases/1.1.2.txt uses "major release" to refer to what is defined by docs/internals/release-process.txt as a "minor release".