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).
--
Ticket URL: <https://code.djangoproject.com/ticket/24106>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* component: Database layer (models, ORM) => Documentation
Old description:
> I believe we don't have a separate ticket for documenting backwards
> incompatible changes to database backend API. In duth 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).
New description:
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).
--
Comment:
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
[https://groups.google.com/d/topic/django-
developers/Z6f4z_zwQYk/discussion 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/24106#comment:1>
* keywords: => 1.8
* severity: Release blocker => Normal
Comment:
I don't think "release blocker" is quite right -- certainly not a blocker
for 1.8 alpha. I'll tag the ticket "1.8" to make sure the issue is
sufficiently addressed by final depending on what feedback we get.
--
Ticket URL: <https://code.djangoproject.com/ticket/24106#comment:2>
* keywords: 1.8 =>
Comment:
Didn't get much response to my mailing post unfortunately.
--
Ticket URL: <https://code.djangoproject.com/ticket/24106#comment:3>
* status: new => closed
* resolution: => wontfix
Comment:
We have been documenting changes as we go for 1.9. Of course, if we get
some contributions for 1.8 I'll be happy to review and merge them.
--
Ticket URL: <https://code.djangoproject.com/ticket/24106#comment:4>