Apologies if this does not directly address your points, but I recently
took over a Django site still running 1.1. I brought it fully up to 1.6 in
under 2 hours work, including rearranging the project structure, updating
settings, URL tags, import paths, switching to pip from buildout etc.
Consider
Mostly for clarity and historical purpose, I'd like to expand on the points
you listed.
Do not take this in any way as a dismissal of the issues you've raised.
On 2 September 2014 06:45, Pkl wrote:
>
> Hello,
>
> I once was once lured to an ideal of long-term stability and
> retrocompatibility,
Pkl, if you're interested, I'd encourage you to be more involved in the
development process including this mailing list when changes are proposed.
I'm afraid raising a whole bunch of old issues that have already been
discussed and decided isn't that helpful.
Our deprecation policy (as you proba
I agree that there have been a lot of backwards-incompatible changes over
the last few years clean up the API. We've really been in "get stuff done"
mode.
I do however think it's a not good idea to break all compatibility in one
single shot. Python 3 did this and 6 years later it's still preven
Hello,
I once was once lured to an ideal of long-term stability and
retrocompatibility, by nice docs like this one :
https://docs.djangoproject.com/en/dev/misc/api-stability/
But for some years, stuffs have actually been getting worse and worse, with
each django release bringing its little cro
On Mon, Sep 1, 2014 at 2:12 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
>
>
> If we recommend HSTS, we need visible warnings and a small duration in
> examples, for people who copy-paste without reading.
>
The default duration should also be less than a day for the exact reas
On 1 sept. 2014, at 19:31, Erik Romijn wrote:
> If I were hosting a Django site on example.com, and enable HSTS with
> includeSubdomains and a lifetime of 6 months, as seems to be common now, I
> might not only break my own site, but also every other side under
> example.com. Upon discovering
I strongly agree, *if at all possible*. What I'm saying is that HSTS can break
so much, even after you revert everything you've changed, that we should make
sure users have a rough idea of determining when it is possible. Please deploy
HSTS everywhere, but only after you've thought through what
Eh, I think we should advise people to switch on HSTS and with
includeSubdomains if at all possible.
> On Sep 1, 2014, at 1:31 PM, Erik Romijn wrote:
>
> Hi all,
>
> I think finally integrating django-secure is a great step. Making a separate
> deploy check also makes sense to me. However, I
Hi all,
I think finally integrating django-secure is a great step. Making a separate
deploy check also makes sense to me. However, I think we should be very
cautious with pushing people to enable HSTS.
Some of our security headers can cause things to break. For example redirecting
to SSL when
Le lundi 1 septembre 2014 09:15:21 UTC+2, Shai Berger a écrit :
>
> A case in point is a change that was introduced in 1.7 -- putting the TEST
> settings of databases into an inner dict. When it was brought up, all
> responses were positive. (...)
(...)
> As I said, everybody who commented on i
Le lundi 1 septembre 2014 02:07:40 UTC+2, Carl Meyer a écrit :
>
> Hi Claude,
>
> On 08/31/2014 12:08 PM, Claude Paroz wrote:
> (...)
>
> > Once again, I'm not advocating for dictionary settings, only for fare
> > debate :-)
>
> I hope you found this email fair ;-)
>
Thanks Carl for developin
This thread has had very little to do with django-secure for some time...
On Sunday 31 August 2014 18:07:04 Carl Meyer wrote:
>
> In the case of the email settings, I think introducing a deprecation
> that requires people to update their settings files, for zero gain in
> capability, is a much bi
13 matches
Mail list logo
