Re: 1.9 release planning

I've attempted to summarize the history of this thread. Note that I marked as +1 any generally positive feedback towards a given proposal, please correct if you feel misrepresented. # First iteration: 1/ Release every 8 months (previously undefined). 2/ LTS every 3rd releases (previously unde

Minor feature request: log adding a custom permission to the database when migrating

Hi I am new to this group so I hope I use the right channels for this request. When I add a custom permission to a model (in 1.7 at least) and then run: migrate the following is logged in the console Operations to perform: Apply all migrations: Running migrations: No migrations to appl

Re: 1.9 release planning

Thanks Loic, that helps A LOT! I'm +1 on a semver or semver-ish policy. I don't have a favorite of the proposed. And I'm +-0 on changing e.g. 1.9 to 2.0 or whatever is required to match the new release policy. /Markus On Tue, Jun 16, 2015 at 02:15:59PM +0700, Loïc Bistuer wrote: I've attempted

Re: Minor feature request: log adding a custom permission to the database when migrating

It already exists, you just need to specify a higher verbosity level like so: manage.py migrate -v 2 On Tuesday, June 16, 2015 at 8:27:14 AM UTC-4, Mikael H wrote: > > Hi > > I am new to this group so I hope I use the right channels for this request. > > When I add a custom permission to a model

Re: Minor feature request: log adding a custom permission to the database when migrating

Thank you! On Tuesday, June 16, 2015 at 2:47:04 PM UTC+2, Tim Graham wrote: > > It already exists, you just need to specify a higher verbosity level like > so: manage.py migrate -v 2 > > On Tuesday, June 16, 2015 at 8:27:14 AM UTC-4, Mikael H wrote: >> >> Hi >> >> I am new to this group so I hope

Re: django.channels: "async" for Django

The in-memory backend is not meant to enable any new functionality, just allow things to run in-place as it currently works - any cross-socket communication would be disabled in that mode. You can already see this in my beta code - trying to run the WebSocket or Worker processes in memory mode will

Re: 1.9 release planning

Thanks Loïc, On 06/16/2015 01:15 AM, Loïc Bistuer wrote: > I've attempted to summarize the history of this thread. Note that I > marked as +1 any generally positive feedback towards a given > proposal, please correct if you feel misrepresented. > [snip] > > # Third iteration: > > 5/ Switching to

Custom Model field, to_python() / from_db_value() and unittests...

I try to create a custom model field, that should "Converting values to Python objects" as described in the documentation here: It doesn't work with Python 2.7 and 3.4 with Django 1.7.x and

Re: 1.9 release planning

I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we sacrifice a little bit of strict semver, but it give some nice meaning to the version numbers. On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer

Re: Custom Model field, to_python() / from_db_value() and unittests...

The doc about how to ignore warnings in tests is here: https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#deprecating-a-feature Alternatively, you can temporarily remove these lines in runtests.py: warnings.simplefilter("error", RemovedInDjango20Warning

Re: how long to support Python 3.3?

On Monday, June 15, 2015 at 7:49:32 AM UTC-6, Tim Graham wrote: > > Here are the cleanups for dropping Python 3.3: > https://github.com/django/django/pull/4861 > > To prevent users from getting stuck on a non-LTS version of Django with an > old version of Python (when they would have had longer s

Re: 1.9 release planning

I'm +1 on the Google doc proposal and like Markus, I support relabeling 1.9 to 2.0 to line the versions up with the new paradigm without the X.1 LTS oddball. Regards, Michael Manfre On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson wrote: > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1

Re: 1.9 release planning

I'm also +1 on the proposal as it stands, and neutral on when the semver versioning should begin. On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote: > > I'm +1 on the Google doc proposal and like Markus, I support relabeling > 1.9 to 2.0 to line the versions up with the new paradi