Re: 1.9 release planning

2015-06-16 Thread Loïc Bistuer 
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 undefined but effectively 1.8 is the 4th 
release after 1.4). Thanks to point 1/ it means one LTS release every two years.

3/ LTS releases are supported for 3 years (previously undefined). Combined with 
points 1/ and 2/ this gives us 1 year of support overlap between 2 LTS 
(currently we committed as an afterthought to 6 months overlap between 1.4 LTS 
and 1.8 LTS).

Core +1: Tim, Marc, Markus, Collin, Aymeric, Loïc


# Second iteration:

4/ Deprecation shims must appear in a LTS release before being dropped.

So far this is the only real change in the policy, first iteration only 
adjusted and/or pinned variables.

In practice, thanks to point 2/, this only requires one exception to our 
current policy: features deprecated in the release *immediately following* an 
LTS have to be supported for 1 extra release. (e.g 1.9 
PendingDeprecationWarning, 2.0 PendingDeprecationWarning, 2.1 
DeprecationWarning). In return this makes it easier for 3rd-party apps to 
straddle 2 LTS releases without writing their own shims (provided their code 
runs without deprecation warnings on the oldest LTS).

Core +1: Collin, Carl, Tim, Anssi, Michael, Loïc

Refs:
- django-compat thread 
(https://groups.google.com/d/topic/django-developers/ASnZ5Uyol6Y/discussion)
- Collin's proposal 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/hou67ofj3EYJ and 
the 7 following responses.


# Third iteration:

5/ Switching to Semantic Versioning

Donald mentioned SemVer on IRC a few days ago. Since then various proposal were 
made to reconcile it with our release policy. So far Collin, Carl, Loïc, Tim, 
and Josh have expressed positive feedback to various proposals in that 
direction but I don't think we have yet reached consensus on a specific one. 
Tim updated the Google doc to reflect my latest proposal, so including me 
that's 2 formal +1 for it, but I'd say we should wait for at least a couple 
more votes before taking it to the technical board.

Refs:
- http://semver.org/
- Carl's analysis 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
- Ryan's proposals 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
- Loïc's proposal 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

Cheers

-- 
Loïc

> On Jun 16, 2015, at 02:37, Aymeric Augustin 
>  wrote:
> 
> If we're approaching consensus, could a kind soul put together a final 
> proposal and submit it to the technical board, along with the main arguments 
> or alternatives? I'm finding it difficult to follow this 50-message thread... 
> Thanks :-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/B8FE1DF4-1542-465B-B3DE-A7CA0DE5C3BB%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

2015-06-16 Thread Mikael H 
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 apply.
  Your models have changes that are not yet reflected in a migration, and 
so won't be applied.
  Run 'manage.py makemigrations' to make new migrations, and then re-run 
'manage.py migrate' to apply them.


The permission is added to the database but it is not showing in the log 
output above which is a bit confusing. When using South it logged what 
permissions were added in addition to the migrations. 

Is this something that can be added?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/21abf685-02f0-467c-85b8-dcdcb4caa751%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

2015-06-16 Thread Markus Holtermann 

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 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 undefined but effectively 1.8 is the 4th 
release after 1.4). Thanks to point 1/ it means one LTS release every two years.

3/ LTS releases are supported for 3 years (previously undefined). Combined with 
points 1/ and 2/ this gives us 1 year of support overlap between 2 LTS 
(currently we committed as an afterthought to 6 months overlap between 1.4 LTS 
and 1.8 LTS).

Core +1: Tim, Marc, Markus, Collin, Aymeric, Loïc


# Second iteration:

4/ Deprecation shims must appear in a LTS release before being dropped.

So far this is the only real change in the policy, first iteration only 
adjusted and/or pinned variables.

In practice, thanks to point 2/, this only requires one exception to our 
current policy: features deprecated in the release *immediately following* an 
LTS have to be supported for 1 extra release. (e.g 1.9 
PendingDeprecationWarning, 2.0 PendingDeprecationWarning, 2.1 
DeprecationWarning). In return this makes it easier for 3rd-party apps to 
straddle 2 LTS releases without writing their own shims (provided their code 
runs without deprecation warnings on the oldest LTS).

Core +1: Collin, Carl, Tim, Anssi, Michael, Loïc

Refs:
- django-compat thread 
(https://groups.google.com/d/topic/django-developers/ASnZ5Uyol6Y/discussion)
- Collin's proposal 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/hou67ofj3EYJ and 
the 7 following responses.


# Third iteration:

5/ Switching to Semantic Versioning

Donald mentioned SemVer on IRC a few days ago. Since then various proposal were 
made to reconcile it with our release policy. So far Collin, Carl, Loïc, Tim, 
and Josh have expressed positive feedback to various proposals in that 
direction but I don't think we have yet reached consensus on a specific one. 
Tim updated the Google doc to reflect my latest proposal, so including me 
that's 2 formal +1 for it, but I'd say we should wait for at least a couple 
more votes before taking it to the technical board.

Refs:
- http://semver.org/
- Carl's analysis 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
- Ryan's proposals 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
- Loïc's proposal 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

Cheers

--
Loïc


On Jun 16, 2015, at 02:37, Aymeric Augustin 
 wrote:

If we're approaching consensus, could a kind soul put together a final proposal 
and submit it to the technical board, along with the main arguments or 
alternatives? I'm finding it difficult to follow this 50-message thread... 
Thanks :-)


--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/B8FE1DF4-1542-465B-B3DE-A7CA0DE5C3BB%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


--

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150616124159.GF25232%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


pgpYsNc2aWalH.pgp
Description: PGP signature

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

2015-06-16 Thread Tim Graham 
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 (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 apply.
>   Your models have changes that are not yet reflected in a migration, and 
> so won't be applied.
>   Run 'manage.py makemigrations' to make new migrations, and then re-run 
> 'manage.py migrate' to apply them.
>
>
> The permission is added to the database but it is not showing in the log 
> output above which is a bit confusing. When using South it logged what 
> permissions were added in addition to the migrations. 
>
> Is this something that can be added?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/45788e70-6e58-4e58-9ea9-2a73ee68f71e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2015-06-16 Thread Mikael H 
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 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 apply.
>>   Your models have changes that are not yet reflected in a migration, and 
>> so won't be applied.
>>   Run 'manage.py makemigrations' to make new migrations, and then re-run 
>> 'manage.py migrate' to apply them.
>>
>>
>> The permission is added to the database but it is not showing in the log 
>> output above which is a bit confusing. When using South it logged what 
>> permissions were added in addition to the migrations. 
>>
>> Is this something that can be added?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4ded4d5d-7bb9-42b8-b5db-f3cdcfd03e7b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django.channels: "async" for Django

2015-06-16 Thread Andrew Godwin 
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 just fail.

Andrew

On Tue, Jun 16, 2015 at 12:48 AM, BearXu  wrote:

> Personally I don't agree with implementing the Channel using in-memory
> mode first. Writing code to communicate among  sockets will become very
> difficult for me(ordinary developer). If we see async in Django as a tool
> instead of a coding style, I think Redis/NoSql/Database backend/ is good
> enough as a first step.
>
> On 15 June 2015 at 03:25, Andrew Godwin  wrote:
>
>> Hello everyone,
>>
>> I've been formulating a plan to decouple Django from the request-response
>> cycle for a couple of years now and after discussing it with some people at
>> DjangoCon Europe I thought it was high time that I actually wrote it up,
>> wrote some code, and solicited feedback.
>>
>> So here it is. The proposal is very long, and is in a Gist here:
>> https://gist.github.com/andrewgodwin/b3f826a879eb84a70625
>>
>> As a top-level summary:
>>
>>  - Fully backwards-compatible
>>  - No actual "in-process" async like asyncio/greenlets (apart from a
>> couple of optional "interface server" modules where you can pick your async
>> implementation)
>>  - New base unit of Django work is no longer the view, it is the channel
>> consumer
>>  - Supports WebSockets, long-polling, offsetting complex tasks outside
>> views and more
>>  - Code looks and works the same - since it'll be a worker model, there's
>> no need to retrofit any core Django APIs for async stuff.
>>
>> To help write the proposal and also to help you understand it, I've
>> semi-implemented the proposal over here as a third-party app:
>> https://github.com/andrewgodwin/django-channels
>>
>> While the goal is to merge this into Django proper, prototyping and
>> iterating outside is much faster and more accessible for everyone involved,
>> and the goal is to get it working on 1.7 and 1.8 (currently only 1.8).
>>
>> The basic chat example in the README of that project is up and running on
>> this code (and the Redis channel backend) here:
>> http://www.aeracode.org/chat/
>>
>> Any and all feedback is welcomed, in this thread is probably best. This
>> is by no means a final plan, but I hope it will lead us towards something
>> that will make Django much more suitable for a modern Web.
>>
>> (I'm about to get on a long flight to Tokyo, so I may not be immediately
>> responsive! And my example might crash, it's only running the websocket
>> server in screen!)
>>
>> Andrew
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAFwN1upKYO7MxyuRigYphJfCqqj%2BKPp_uhBgymEK2oMtP%2BJMPA%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAB%2B2MZygJ10J8_bPFkE8AR%3D1mQ%3D0KKWWvXvoHhnmKaVJzZFBGQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1urENRO2bFVVncpbF_Dymv0Z1PAVUJxHW7kOScubCg4sJg%40mail.gmail.com.
For more options, visit

Re: 1.9 release planning

2015-06-16 Thread Carl Meyer 
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 Semantic Versioning
> 
> Donald mentioned SemVer on IRC a few days ago. Since then various
> proposal were made to reconcile it with our release policy. So far
> Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to
> various proposals in that direction but I don't think we have yet
> reached consensus on a specific one. Tim updated the Google doc to
> reflect my latest proposal, so including me that's 2 formal +1 for
> it, but I'd say we should wait for at least a couple more votes
> before taking it to the technical board.
> 
> Refs: - http://semver.org/ - Carl's analysis
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
>
> 
- Ryan's proposals
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
> - Loïc's proposal
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

FWIW, I am also +1 on your proposal, as currently documented in the
Google doc.

I was trying to come up with a proposal where LTS == major release for
the sake of argument, since it seemed like that was intuitive to at
least some people, but it's not worth the required lengthening of
deprecation paths. Your proposal is much better. (And it does make some
intuitive sense for the _last_ minor release in a major series to be LTS
rather than the first).

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55804D47.5030802%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

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

2015-06-16 Thread Jens Diemer 


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 1.8.x...


I search around and found no unittest case for this "howto/custom-model-fields"

So i created a simple test case to investigate why my code not worked.


I made a unittest against "stable/1.7.x", "stable/1.8.x" and "master" here:

https://github.com/jedie/django/branches/yours

compare links:

stable/1.7.x


stable/1.8.x


master



I run these test and here the result:


*** 1.7.x with Py2:
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_values (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... ok
test_values (custom_model_fields.tests.TestModel2Tests) ... FAIL


*** 1.7.x with Py3:
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_values (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... FAIL
test_values (custom_model_fields.tests.TestModel2Tests) ... FAIL



*** 1.8.x with Py2:
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok
test_values (custom_model_fields.tests.TestModel1Tests) ... ok


*** 1.8.x with Py3
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok
test_values (custom_model_fields.tests.TestModel1Tests) ... ok



*** master with Py2 - doesn't run:
Traceback (most recent call last):
  File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 12, in 

from django.apps import apps
  File "/home/jens/PyLucid_env/src/django/django/apps/__init__.py", line 1, in 


from .config import AppConfig   # NOQA
  File "/home/jens/PyLucid_env/src/django/django/apps/config.py", line 6, in 


from django.utils.module_loading import module_has_submodule
  File "/home/jens/PyLucid_env/src/django/django/utils/module_loading.py", line 
4, in 

from importlib import import_module
  File "/home/jens/PyLucid_env/src/django/django/utils/importlib.py", line 6, 
in 

ImportError: cannot import name RemovedInDjango19Warning



*** master with Py3:
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok
test_values (custom_model_fields.tests.TestModel1Tests) ... ok
test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... ok
test_values (custom_model_fields.tests.TestModel2Tests) ... ok




So the biggest problem is django 1.7.x...
But it should work in the same way:



With 1.8.x i must remove the test with existing:
__metaclass__ = models.SubfieldBase


Otherwise the test will not run:

Testing against Django installed in '/home/jens/PyLucid_env/src/django/django'
Importing application custom_model_fields
Traceback (most recent call last):
  File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 448, in 

options.debug_sql)
  File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 235, in 
django_tests

state = setup(verbosity, test_labels)
  File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 214, in setup
apps.set_installed_apps(settings.INSTALLED_APPS)
  File "/home/jens/PyLucid_env/src/django/django/apps/registry.py", line 324, 
in set_installed_apps

self.populate(installed)
  File "/home/jens/PyLucid_env/src/django/django/apps/registry.py", line 108, 
in populate

app_config.import_models(all_models)
  File "/home/jens/PyLucid_env/src/django/django/apps/config.py", line 198, in 
import_models

self.models_module = import_module(models_module_name)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File "/home/jens/PyLucid_env/src/django/tests/custom_model_fields/models.py", 
line 41, in 

class CommaSeparatedModelField2(CommaSeparatedModelField1):
  File 
"/home/jens/PyLucid_env/src/django/django/db/models/fields/subclassing.py", line 
22, in __new__

RemovedInDjango20Warning)
django.utils.deprecation.RemovedInDjango20Warning: SubfieldBase has been 
deprecated. Use Field.from_db_value instead.




Maybe i miss something to handle warnings with tests, but didn't find something 
about warnings here:


https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/



--


Mfg.

Jens Diemer



http://www.jensdiemer.de

--
You received this message because you are subscribed to the Google

Re: 1.9 release planning

2015-06-16 Thread Collin Anderson 
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 wrote:
>
> 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 Semantic Versioning 
> > 
> > Donald mentioned SemVer on IRC a few days ago. Since then various 
> > proposal were made to reconcile it with our release policy. So far 
> > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to 
> > various proposals in that direction but I don't think we have yet 
> > reached consensus on a specific one. Tim updated the Google doc to 
> > reflect my latest proposal, so including me that's 2 formal +1 for 
> > it, but I'd say we should wait for at least a couple more votes 
> > before taking it to the technical board. 
> > 
> > Refs: - http://semver.org/ - Carl's analysis 
> > 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
> > 
> > 
> - Ryan's proposals 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
> > - Loïc's proposal 
> > 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
>
> FWIW, I am also +1 on your proposal, as currently documented in the 
> Google doc. 
>
> I was trying to come up with a proposal where LTS == major release for 
> the sake of argument, since it seemed like that was intuitive to at 
> least some people, but it's not worth the required lengthening of 
> deprecation paths. Your proposal is much better. (And it does make some 
> intuitive sense for the _last_ minor release in a major series to be LTS 
> rather than the first). 
>
> Carl 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2015-06-16 Thread Tim Graham 
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)
warnings.simplefilter("error", RemovedInDjango21Warning)

On Tuesday, June 16, 2015 at 12:30:05 PM UTC-4, Jens Diemer wrote:
>
>
> I try to create a custom model field, that should "Converting values to 
> Python 
> objects" as described in the documentation here: 
>
> <
> https://docs.djangoproject.com/en/dev/howto/custom-model-fields/#converting-values-to-python-objects>
>  
>
>
> It doesn't work with Python 2.7 and 3.4 with Django 1.7.x and 1.8.x... 
>
>
> I search around and found no unittest case for this 
> "howto/custom-model-fields" 
>
> So i created a simple test case to investigate why my code not worked. 
>
>
> I made a unittest against "stable/1.7.x", "stable/1.8.x" and "master" 
> here: 
>
> https://github.com/jedie/django/branches/yours 
>
> compare links: 
>
> stable/1.7.x 
> <
> https://github.com/jedie/django/compare/stable/1.7.x...test_custom_model_fields_1.7.x>
>  
>
>
> stable/1.8.x 
> <
> https://github.com/jedie/django/compare/stable/1.8.x...test_custom_model_fields_1.8.x>
>  
>
>
> master 
> <
> https://github.com/jedie/django/compare/master...test_custom_model_fields_master>
>  
>
>
>
> I run these test and here the result: 
>
>
> *** 1.7.x with Py2: 
> test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... 
> FAIL 
> test_values (custom_model_fields.tests.TestModel1Tests) ... FAIL 
> test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... ok 
> test_values (custom_model_fields.tests.TestModel2Tests) ... FAIL 
>
>
> *** 1.7.x with Py3: 
> test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... 
> FAIL 
> test_values (custom_model_fields.tests.TestModel1Tests) ... FAIL 
> test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... 
> FAIL 
> test_values (custom_model_fields.tests.TestModel2Tests) ... FAIL 
>
>
>
> *** 1.8.x with Py2: 
> test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok 
> test_values (custom_model_fields.tests.TestModel1Tests) ... ok 
>
>
> *** 1.8.x with Py3 
> test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok 
> test_values (custom_model_fields.tests.TestModel1Tests) ... ok 
>
>
>
> *** master with Py2 - doesn't run: 
> Traceback (most recent call last): 
>File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 12, in 
>  
>  from django.apps import apps 
>File "/home/jens/PyLucid_env/src/django/django/apps/__init__.py", line 
> 1, in 
>  
>  from .config import AppConfig   # NOQA 
>File "/home/jens/PyLucid_env/src/django/django/apps/config.py", line 6, 
> in 
>  
>  from django.utils.module_loading import module_has_submodule 
>File 
> "/home/jens/PyLucid_env/src/django/django/utils/module_loading.py", line 
> 4, in  
>  from importlib import import_module 
>File "/home/jens/PyLucid_env/src/django/django/utils/importlib.py", 
> line 6, 
> in  
> ImportError: cannot import name RemovedInDjango19Warning 
>
>
>
> *** master with Py3: 
> test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok 
> test_values (custom_model_fields.tests.TestModel1Tests) ... ok 
> test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... ok 
> test_values (custom_model_fields.tests.TestModel2Tests) ... ok 
>
>
>
>
> So the biggest problem is django 1.7.x... 
> But it should work in the same way: 
> <
> https://docs.djangoproject.com/en/1.7/howto/custom-model-fields/#converting-database-values-to-python-objects>
>  
>
>
>
> With 1.8.x i must remove the test with existing: 
> __metaclass__ = models.SubfieldBase 
>
>
> Otherwise the test will not run: 
>
> Testing against Django installed in 
> '/home/jens/PyLucid_env/src/django/django' 
> Importing application custom_model_fields 
> Traceback (most recent call last): 
>File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 448, 
> in  
>  options.debug_sql) 
>File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 235, 
> in 
> django_tests 
>  state = setup(verbosity, test_labels) 
>File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 214, 
> in setup 
>  apps.set_installed_apps(settings.INSTALLED_APPS) 
>File "/home/jens/PyLucid_env/src/django/django/apps/registry.py", line 
> 324, 
> in set_installed_apps 
>  self.populate(installed) 
>File "/home/jens/PyLucid_env/src/django/django/apps/registry.py", line 
> 108, 
> in populate 
>  app_config.import_models(all_models) 
>File "/home/jens/PyLucid_env/src/django/django/apps/config.py", line 
> 198, in 
> import_models 
>  self.models_module = import_module(models_module_name) 
>File "/usr/lib/python2.7/importlib/

Re: how long to support Python 3.3?

2015-06-16 Thread Carl Meyer 
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 support had they 
> stuck with an LTS), the policy I suggest we adopt is:
>
> Typically, we will support a Python version up to and including the first
> Django LTS release that will receive security updates until after security
> support for that version of Python ends. For example, Python 3.3 security
> support ends September 2017 and Django 1.8 LTS security support ends April
> 2018. Therefore Django 1.8 is the last version to support Python 3.3.
>

I think this policy makes sense. It aligns nicely with the direction the 
new releases policy is heading, which is that the release right after an 
LTS is the one where more backwards-incompatible changes tend to 
concentrate (and the one where we bump the major version number).

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7021353c-7820-4333-a01e-834948db7ffe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

2015-06-16 Thread Michael Manfre 
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 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 wrote:
>>
>> 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 Semantic Versioning
>> >
>> > Donald mentioned SemVer on IRC a few days ago. Since then various
>> > proposal were made to reconcile it with our release policy. So far
>> > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to
>> > various proposals in that direction but I don't think we have yet
>> > reached consensus on a specific one. Tim updated the Google doc to
>> > reflect my latest proposal, so including me that's 2 formal +1 for
>> > it, but I'd say we should wait for at least a couple more votes
>> > before taking it to the technical board.
>> >
>> > Refs: - http://semver.org/ - Carl's analysis
>> >
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
>> >
>> >
>> - Ryan's proposals
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
>> > - Loïc's proposal
>> >
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ
>>
>> FWIW, I am also +1 on your proposal, as currently documented in the
>> Google doc.
>>
>> I was trying to come up with a proposal where LTS == major release for
>> the sake of argument, since it seemed like that was intuitive to at
>> least some people, but it's not worth the required lengthening of
>> deprecation paths. Your proposal is much better. (And it does make some
>> intuitive sense for the _last_ minor release in a major series to be LTS
>> rather than the first).
>>
>> Carl
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBvLzcDHTfFQebw0gbJ%3DodJMxcVcYoiUXQ2HOpqicym3SA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

2015-06-16 Thread Josh Smeaton 
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 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 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 wrote:
>>>
>>> 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 Semantic Versioning 
>>> > 
>>> > Donald mentioned SemVer on IRC a few days ago. Since then various 
>>> > proposal were made to reconcile it with our release policy. So far 
>>> > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to 
>>> > various proposals in that direction but I don't think we have yet 
>>> > reached consensus on a specific one. Tim updated the Google doc to 
>>> > reflect my latest proposal, so including me that's 2 formal +1 for 
>>> > it, but I'd say we should wait for at least a couple more votes 
>>> > before taking it to the technical board. 
>>> > 
>>> > Refs: - http://semver.org/ - Carl's analysis 
>>> > 
>>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
>>> > 
>>> > 
>>> - Ryan's proposals 
>>>
>>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
>>> > - Loïc's proposal 
>>> > 
>>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
>>>
>>> FWIW, I am also +1 on your proposal, as currently documented in the 
>>> Google doc. 
>>>
>>> I was trying to come up with a proposal where LTS == major release for 
>>> the sake of argument, since it seemed like that was intuitive to at 
>>> least some people, but it's not worth the required lengthening of 
>>> deprecation paths. Your proposal is much better. (And it does make some 
>>> intuitive sense for the _last_ minor release in a major series to be LTS 
>>> rather than the first). 
>>>
>>> Carl 
>>>
>>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> GPG Fingerprint: 74DE D158 BAD0 EDF8
> keybase.io/manfre
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/79aae5a5-58dd-4f05-a6dd-35685e06ebb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.