Opened 10 years ago
Last modified 9 years ago
#24106 closed New feature
Document backwards incompatible changes to database backend API — at Version 1
Reported by: | Anssi Kääriäinen | Owned by: | nobody |
---|---|---|---|
Component: | Documentation | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
I believe we don't have a separate ticket for documenting backwards incompatible changes to database backend API. At Django Under the Hood it was agreed that we want to do this.
An idea of how to do this is to log/diff changes to Django's backends between stable/1.7 and master. Going through the changes in Django should give a good approximation of all the breaking changes (another place where breakage is possible is Compiler module).
If possible, I'd like to document the changes in a way that is both backwards and forwards compatible. That is, we give a replacement suggestion that works both in 1.7 and 1.8 (very likely conditional on Django version).
Change History (1)
comment:1 by , 10 years ago
Component: | Database layer (models, ORM) → Documentation |
---|---|
Description: | modified (diff) |
In my opinion, there is no need to document the changes in a way that is both backwards and forwards compatible. django-mssql, at least, does not attempt to support multiple versions of Django. I believe try to support multiple versions of Django would be more effort than it's worth (after all, we don't have this required for any backends in core), but maybe there are backends out there that attempt to do so. I have created a thread on django-developers to get feedback on this question and more, so that we have some guidance on what documentation to add. Since we haven't been documenting as we go this time, I believe the most efficient way to add this documentation will be to do so in a reactive fashion (to reported breakages in third-party backends) rather than trying to anticipate what parts of the API developers are using.