Hello,
I've *at last* had some time to experiment with the idea I had thrown years
again, of a system to workaround the recurring breakages introduced by new
django releases, breakages which sometimes lead to unreconcilable
requirements between django apps.
After a sprint at PyconFR, with a c
Our new deprecation policy was designed to eliminate the need for this type
of compatibility library. If you want to support more Django versions than
what our guidelines recommend (which may involve supporting versions that
no longer receive security updates), I guess this library could be usef
Hello,
thanks for your feedback,
Actually this DCP layer is mainly aimed at backwards compatibility of
dependencies : running, on the latest version of django (with maximal
security bugfixes), older reusable apps which are incompatible with
each-other, or with said latest version of Django.
> "*Django promises API stability and forwards-compatibility since version
1.0. In a nutshell, this means that code you develop against a version of
Django will continue to work with future releases*." were imho untrue.
Perhaps the API stability statements are too strong and need some
clarifica
I agree that reading the whole document gave some hints about the incoming
troubles, but I guess many people (like me), on first pass, just thought
"OK that's all I wanted to hear" and went by. Plus, it's a little like
saying "this dogs doesn't bite", and then later "if the dogs wants to bite
you,
I agree that reading the whole document gave some hints about the incoming
troubles, but I guess many people (like me), on first pass, just thought
"OK that's all I wanted to hear" and went by. Plus, it's a little like
saying "this dogs doesn't bite", and then later "if the dogs wants to bite
y
If you've been maintaining several django apps for several versions of
Django (ie. stable, oldstable, lts) then it's pretty easy to imagine how
useful this can be. The deprecation policy removes the need of a
compatibility layer for code that should support only one version of
Django, but does not
On Sun, Jan 15, 2017 at 1:09 PM, Pkl wrote:
> My bad, if people are guaranteed 2 x 24-month cycles before a feature gets
> removed, it's already much better. However, the same pattern as previously
> appears in docs : "each feature release will continue to have a few
> documented backwards incomp
Hi,
@James Pc - thanks for the support, if you happen to miss some fixers in
DCP and don't have the opportunity to contribute them, please open an issue
so that I have a look
@Tim Graham & James James Bennett - from what I sum up, the new policy
simply extends the delay between breaking changes,
Hi,
Making Django upgrades less painful is a great goal, but I believe the
patching Django and restoring removed functionality is not the right
solution. JavaScript world has the same problem with far more frequent
major compatibility breakages and they solve it with automatic codebase
upgrade too
Hi Dmitry,
thanks for the alternative way, however it seems more a *complement *than a
replacement of DCP.
Indeed, your "rewriting" approach updates a codebase to support the latest
django API, but it raises a number of issues :
- how could it be applied to django reusable apps, installed via pi
Hi Pascal,
I'm unsure as to what problem you're trying to solve; if I understand
correctly, this project aims at making a "new"
Django behave like an "old" one.
I see a few possible use cases in the conversation:
* Running a legacy application (without new development) beyond the upstream
sup
Hi Raphaël ,
the goal of DCP is to "unite" the behaviour of different django versions,
so that all the code needed by a project (misc. pypi dependencies, as well
as custom project modules) may work together, whatever the exact django
version each of these module actually targets. That's closer to
13 matches
Mail list logo