Re: 1.9 release planning

[Marc Tamlyn]

This looks like a good plan to me. The main reason for shortening it before
as far as I could tell was the lengthy alpha to final process, which hasn't
happened this time and hopefully will be rather less frequent in future.

Marc

On 7 April 2015 at 00:21, Tim Graham  wrote:

> With a 9 month schedule, here is what the future might look like:
>
> 1.8 - April 2015
> 1.9 - January 2016
> 2.0 - October 2016
> 2.1 - July 2017 (LTS, and might be the last version to support Python 2.7
> since 3 years of LTS support would cover until the 2020 sunset.)
> 2.2 - April 2018
>
> Do you think there would be any value in putting together a short survey
> for the community to get a wider consensus?
>
>
> On Monday, April 6, 2015 at 5:30:40 PM UTC-4, Shai Berger wrote:
>>
>> On Monday 06 April 2015 23:34:09 Chris Foresman wrote:
>> > I'm really curious to know if the version to follow 1.9 is planned to
>> be
>> > 2.0 or 1.10. I feel as though 1.x releases have had a lot of major
>> feature
>> > changes. Maybe it's time to start thinking about features in terms of
>> > major, minor, and bugfix/security patch, and start saving major
>> features
>> > for a 2.0 release that could be LTS. In the meantime, minor features
>> could
>> > be added to 1.9, 1.10, 1.11, etc, and breaking API changes should be
>> added
>> > to 2.x, or 3.x, etc. This would make it (IMO) easier to evaluate
>> upgrade
>> > paths, while maintaining the six-month cadence for .x releases of minor
>> > features.
>> >
>> This was decided a little before 1.7 was released: the version after 1.9
>> will
>> be called 2.0, but it is not going to break things more than earlier
>> releases
>> (there are already warning classes named RemovedInDjango20Warning and
>> RemovedInDjango21Warning in the sources, anticipating the releases after
>> 1.9).
>>
>> Shai.
>>
>  --
> 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/56675028-6c26-4f72-9491-98f2db0f529e%40googlegroups.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/CAMwjO1FBi1f1wOYXAThzT0OfZt9JekO5g53jcy5uOtn%2B9uw58g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

render_to_response in Django 1.8 missing a request parameter?

[Stephen Brooks]

I note from the release notes for Django 1.8 
https://docs.djangoproject.com/en/1.8/releases/1.8/ the remark under the 
section:
"dictionary and context_instance arguments of rendering functions" (which 
includes django.shortcuts.render_to_response())

"If you’re passing a Context 

 
in context_instance, pass a dict 
 in the context 
parameter instead. If you’re passing a RequestContext 
,
 
pass the request separately in the *request *parameter."

However, render_to_response* does not have a request parameter*. Is that an 
omission?

I use the following idiom quite a lot:

response = render_to_response('some_template.html', {'foo': 'bar'}, 
RequestContext(request))

If the passing of a context_instance is now to be avoided, I would expect 
to be able pass in the request object directly to render_to_response. 
Otherwise how are the context processors to do their job?

-- Stephen

-- 
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/e9b54373-9901-4a5a-8101-89b6a7cedaf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: render_to_response in Django 1.8 missing a request parameter?

[Marc Tamlyn]

This is probably a slight error in the documentation, however what you
really want to use is the `render()` function when you want a request
context.

See https://docs.djangoproject.com/en/1.8/topics/http/shortcuts/#render

On 7 April 2015 at 11:28, Stephen Brooks  wrote:

> I note from the release notes for Django 1.8
> https://docs.djangoproject.com/en/1.8/releases/1.8/ the remark under the
> section:
> "dictionary and context_instance arguments of rendering functions" (which
> includes django.shortcuts.render_to_response())
>
> "If you’re passing a Context
> 
> in context_instance, pass a dict
>  in the context
> parameter instead. If you’re passing a RequestContext
> ,
> pass the request separately in the *request *parameter."
>
> However, render_to_response* does not have a request parameter*. Is that
> an omission?
>
> I use the following idiom quite a lot:
>
> response = render_to_response('some_template.html', {'foo': 'bar'},
> RequestContext(request))
>
> If the passing of a context_instance is now to be avoided, I would expect
> to be able pass in the request object directly to render_to_response.
> Otherwise how are the context processors to do their job?
>
> -- Stephen
>
> --
> 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/e9b54373-9901-4a5a-8101-89b6a7cedaf6%40googlegroups.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/CAMwjO1HqvgMm0_RKdYqt2XVbb%3DsKEjzvb6f0Vpsw_J2kifAcXw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Markus Holtermann]

On Tuesday, April 7, 2015 at 1:21:20 AM UTC+2, Tim Graham wrote:
>
> With a 9 month schedule, here is what the future might look like:
>
> 1.8 - April 2015
> 1.9 - January 2016
> 2.0 - October 2016
> 2.1 - July 2017 (LTS, and might be the last version to support Python 2.7 
> since 3 years of LTS support would cover until the 2020 sunset.)
> 2.2 - April 2018
>
> Do you think there would be any value in putting together a short survey 
> for the community to get a wider consensus?
>

I think the above schedule is a good trade-off between giving companies 
time for their bureaucracy and getting features out to users frequently 
(those who can't (as in "don't want to") wait to use the new features can 
always use the release branch and get involved in testing).

I like the idea of getting the community involved here. But what are we 
planning to say if the majority says "no, that's too often / not often 
enough"? Both, more frequent releases and less frequent releases as they 
happened in the past, have their pros and cons.
 
Markus

On Monday, April 6, 2015 at 5:30:40 PM UTC-4, Shai Berger wrote:
>>
>> On Monday 06 April 2015 23:34:09 Chris Foresman wrote: 
>> > I'm really curious to know if the version to follow 1.9 is planned to 
>> be 
>> > 2.0 or 1.10. I feel as though 1.x releases have had a lot of major 
>> feature 
>> > changes. Maybe it's time to start thinking about features in terms of 
>> > major, minor, and bugfix/security patch, and start saving major 
>> features 
>> > for a 2.0 release that could be LTS. In the meantime, minor features 
>> could 
>> > be added to 1.9, 1.10, 1.11, etc, and breaking API changes should be 
>> added 
>> > to 2.x, or 3.x, etc. This would make it (IMO) easier to evaluate 
>> upgrade 
>> > paths, while maintaining the six-month cadence for .x releases of minor 
>> > features. 
>> > 
>> This was decided a little before 1.7 was released: the version after 1.9 
>> will 
>> be called 2.0, but it is not going to break things more than earlier 
>> releases 
>> (there are already warning classes named RemovedInDjango20Warning and   
>> RemovedInDjango21Warning in the sources, anticipating the releases after 
>> 1.9). 
>>
>> Shai. 
>>
>

-- 
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/c151c546-dfe1-46f9-9f89-4bc8ee68b133%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: render_to_response in Django 1.8 missing a request parameter?

[Stephen Brooks]

In that case the render_to_response shortcut has little value and should 
probably be removed in Django 2.0 ??

On Tuesday, 7 April 2015 11:31:24 UTC+1, Marc Tamlyn wrote:
>
> This is probably a slight error in the documentation, however what you 
> really want to use is the `render()` function when you want a request 
> context.
>
> See https://docs.djangoproject.com/en/1.8/topics/http/shortcuts/#render
>
> On 7 April 2015 at 11:28, Stephen Brooks > 
> wrote:
>
>> I note from the release notes for Django 1.8 
>> https://docs.djangoproject.com/en/1.8/releases/1.8/ the remark under the 
>> section:
>> "dictionary and context_instance arguments of rendering functions" (which 
>> includes django.shortcuts.render_to_response())
>>
>> "If you’re passing a Context 
>> 
>>  
>> in context_instance, pass a dict 
>>  in the context 
>> parameter instead. If you’re passing a RequestContext 
>> ,
>>  
>> pass the request separately in the *request *parameter."
>>
>> However, render_to_response* does not have a request parameter*. Is that 
>> an omission?
>>
>> I use the following idiom quite a lot:
>>
>> response = render_to_response('some_template.html', {'foo': 'bar'}, 
>> RequestContext(request))
>>
>> If the passing of a context_instance is now to be avoided, I would expect 
>> to be able pass in the request object directly to render_to_response. 
>> Otherwise how are the context processors to do their job?
>>
>> -- Stephen
>>
>> -- 
>> 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/e9b54373-9901-4a5a-8101-89b6a7cedaf6%40googlegroups.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/2066cb5c-514e-4ccb-bd5e-442f7b2d60ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: render_to_response in Django 1.8 missing a request parameter?

[Marc Tamlyn]

The purpose of render_to_response is "render without a request context" now
as far as I can tell. There are reasons why you would do this, whether they
justify the existence of the shortcut is another question.

On 7 April 2015 at 11:37, Stephen Brooks  wrote:

> In that case the render_to_response shortcut has little value and should
> probably be removed in Django 2.0 ??
>
> On Tuesday, 7 April 2015 11:31:24 UTC+1, Marc Tamlyn wrote:
>>
>> This is probably a slight error in the documentation, however what you
>> really want to use is the `render()` function when you want a request
>> context.
>>
>> See https://docs.djangoproject.com/en/1.8/topics/http/shortcuts/#render
>>
>> On 7 April 2015 at 11:28, Stephen Brooks  wrote:
>>
>>> I note from the release notes for Django 1.8 https://docs.djangoproject.
>>> com/en/1.8/releases/1.8/ the remark under the section:
>>> "dictionary and context_instance arguments of rendering functions" (which
>>> includes django.shortcuts.render_to_response())
>>>
>>> "If you’re passing a Context
>>> 
>>> in context_instance, pass a dict
>>>  in the context
>>> parameter instead. If you’re passing a RequestContext
>>> ,
>>> pass the request separately in the *request *parameter."
>>>
>>> However, render_to_response* does not have a request parameter*. Is
>>> that an omission?
>>>
>>> I use the following idiom quite a lot:
>>>
>>> response = render_to_response('some_template.html', {'foo': 'bar'},
>>> RequestContext(request))
>>>
>>> If the passing of a context_instance is now to be avoided, I would
>>> expect to be able pass in the request object directly to
>>> render_to_response. Otherwise how are the context processors to do their
>>> job?
>>>
>>> -- Stephen
>>>
>>> --
>>> 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/e9b54373-9901-4a5a-8101-
>>> 89b6a7cedaf6%40googlegroups.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/2066cb5c-514e-4ccb-bd5e-442f7b2d60ea%40googlegroups.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/CAMwjO1Ejtx%2BaQvSczLAR%3DdAPq%3D3nLMiBgZo68bj40WryOZw2LA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: render_to_response in Django 1.8 missing a request parameter?

[Aymeric Augustin]

Hi Stephen,

The only difference between render_to_response and render is that
render_to_response doesn't know about the current request while render does.

If you were using:

response = render_to_response('some_template.html', {'foo': 'bar'},
RequestContext(request))

Now you should use:

response = render(request, 'some_template.html', {'foo': 'bar'})

The latter idiom works since Django 1.3 and has obsoleted the former in
many projects.

-- 
Aymeric.




2015-04-07 12:28 GMT+02:00 Stephen Brooks :

> I note from the release notes for Django 1.8
> https://docs.djangoproject.com/en/1.8/releases/1.8/ the remark under the
> section:
> "dictionary and context_instance arguments of rendering functions" (which
> includes django.shortcuts.render_to_response())
>
> "If you’re passing a Context
> 
> in context_instance, pass a dict
>  in the context
> parameter instead. If you’re passing a RequestContext
> ,
> pass the request separately in the *request *parameter."
>
> However, render_to_response* does not have a request parameter*. Is that
> an omission?
>
> I use the following idiom quite a lot:
>
> response = render_to_response('some_template.html', {'foo': 'bar'},
> RequestContext(request))
>
> If the passing of a context_instance is now to be avoided, I would expect
> to be able pass in the request object directly to render_to_response.
> Otherwise how are the context processors to do their job?
>
> -- Stephen
>
> --
> 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/e9b54373-9901-4a5a-8101-89b6a7cedaf6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aymeric.

-- 
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/CANE-7mVTCh%3DPh0L5X_t_HOgzNkyJV49%2BkHT035arwTUM3BXgmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[elky]

Hi everyone. As you can see there is less activity now in this thread. With 
the latest 0.9.3 release I just think CSS work is over until anyone report 
a bug or suggestion to improvement.

There is big interest from the community:
- 1736 downloads in the last month from PyPi 

- 334 unique visitors of the repo 
 and 117 stars

People actively use this theme so it's time to think what do to next.

I would like to make Pull Request in Django 1.9 branch when it starts - but 
I need feedback and suggestions before. Please share your thoughts, guys.

I manually found interesting discussion here 
. Few words 
on flat icons - I think it requires markup change but if people really want 
to see flat icons I suggest to use one of the popular icon font library (like 
I suggested in October 
).
 
Any thoughts?

Thanks,
Alex

-- 
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/8e0d0669-6c37-4c44-9d07-6ac625413492%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Collin Anderson]

There's a ticket about icons here: 
https://code.djangoproject.com/ticket/20597

On Tuesday, April 7, 2015 at 11:16:42 AM UTC-4, elky wrote:
>
> Hi everyone. As you can see there is less activity now in this thread. 
> With the latest 0.9.3 release I just think CSS work is over until anyone 
> report a bug or suggestion to improvement.
>
> There is big interest from the community:
> - 1736 downloads in the last month from PyPi 
> 
> - 334 unique visitors of the repo 
>  and 117 stars
>
> People actively use this theme so it's time to think what do to next.
>
> I would like to make Pull Request in Django 1.9 branch when it starts - 
> but I need feedback and suggestions before. Please share your thoughts, 
> guys.
>
> I manually found interesting discussion here 
> . Few 
> words on flat icons - I think it requires markup change but if people 
> really want to see flat icons I suggest to use one of the popular icon font 
> library (like I suggested in October 
> ).
>  
> Any thoughts?
>
> Thanks,
> Alex
>
>

-- 
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/0e2a071a-6240-47e5-8d85-9dd11acbd087%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Marc Tamlyn]

Django's master is the correct branch for 1.9 development now.

Flat icons would be good, and I agree personally with your earlier
suggestion to use font awesome icons. I do think this is a separate issue
we could add later.

The primary questions to establish answers to before a possible merge in my
opinion are:
- Do we ship both, or just the new one and release the old one as a third
party package?
- How could we identify the difference for third party app developers who
integrate with both versions, at least across the 1.8/1.9 release cycle?
The easy answer here would be to add a new body class, potentially to both
versions.

My suggestion would be that we should publicise via this mailing list (and
django-users etc) that we are planning to integrate this, and you can use
it now via your app. This should hopefully get you more bug reports early
and we can merge it in a more finished state for the 1.9 alpha.

On 7 April 2015 at 16:16, elky  wrote:

> Hi everyone. As you can see there is less activity now in this thread.
> With the latest 0.9.3 release I just think CSS work is over until anyone
> report a bug or suggestion to improvement.
>
> There is big interest from the community:
> - 1736 downloads in the last month from PyPi
> 
> - 334 unique visitors of the repo
>  and 117 stars
>
> People actively use this theme so it's time to think what do to next.
>
> I would like to make Pull Request in Django 1.9 branch when it starts -
> but I need feedback and suggestions before. Please share your thoughts,
> guys.
>
> I manually found interesting discussion here
> . Few
> words on flat icons - I think it requires markup change but if people
> really want to see flat icons I suggest to use one of the popular icon font
> library (like I suggested in October
> ).
> Any thoughts?
>
> Thanks,
> Alex
>
>  --
> 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/8e0d0669-6c37-4c44-9d07-6ac625413492%40googlegroups.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/CAMwjO1H6rLP8uFh6bHVjeTdnrx3jNXfwqkQWvX9cqk%2BoCuYgdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[elky]

On Tuesday, 7 April 2015 20:23:28 UTC+5, Collin Anderson wrote:
>
> There's a ticket about icons here: 
> https://code.djangoproject.com/ticket/20597
>
 
Thanks Collin.


On Tuesday, 7 April 2015 20:25:57 UTC+5, Marc Tamlyn wrote:
>
> The primary questions to establish answers to before a possible merge in 
> my opinion are:
> - Do we ship both, or just the new one and release the old one as a third 
> party package?
>

If we release old one as a third-party app we need to support it as well. 
And it is additional headache for the third-party apps developers.  
 

> - How could we identify the difference for third party app developers who 
> integrate with both versions, at least across the 1.8/1.9 release cycle? 
> The easy answer here would be to add a new body class, potentially to both 
> versions.
>

How we can add this class? Someone suggested a setting to enable new theme. 
Ideally Django needs something like CSS framework because as far as I can 
see most of apps just uses their own styles and markup.
 

> My suggestion would be that we should publicise via this mailing list (and 
> django-users etc) that we are planning to integrate this, and you can use 
> it now via your app. This should hopefully get you more bug reports early 
> and we can merge it in a more finished state for the 1.9 alpha.
>
 
That would be great.

-- 
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/0a3c2428-fe8e-48de-9b25-c658446548a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Marc Tamlyn]

We would modify our base admin template when we merge it. There are a
number of third party applications which provide modified versions of their
admin pages (FeinCMS is a good example of a moderately complex one). They
would normally support two versions of Django (maybe also an LTS now), and
so would need to provide one code base which works with both. So the
shipping of and old one doesn't make third party app developers headache
any worse.

We will need to release the old one as a third party app, or ship both for
a deprecation period because of users own admin style changes and overrides
they may have made.

I'm not sure the best approach for swapping between the two, even if they
are shipped separately. Perhaps the easiest option is to ship both
versions, add an AdminSite.theme parameter set to the new one. The main
issue I can see with this would be two lots of static files collected every
time (annoying for S3 users), but this is liveable with.

On 7 April 2015 at 16:52, elky  wrote:

> On Tuesday, 7 April 2015 20:23:28 UTC+5, Collin Anderson wrote:
>>
>> There's a ticket about icons here: https://code.djangoproject.
>> com/ticket/20597
>>
>
> Thanks Collin.
>
>
> On Tuesday, 7 April 2015 20:25:57 UTC+5, Marc Tamlyn wrote:
>>
>> The primary questions to establish answers to before a possible merge in
>> my opinion are:
>> - Do we ship both, or just the new one and release the old one as a third
>> party package?
>>
>
> If we release old one as a third-party app we need to support it as well.
> And it is additional headache for the third-party apps developers.
>
>
>> - How could we identify the difference for third party app developers who
>> integrate with both versions, at least across the 1.8/1.9 release cycle?
>> The easy answer here would be to add a new body class, potentially to both
>> versions.
>>
>
> How we can add this class? Someone suggested a setting to enable new
> theme. Ideally Django needs something like CSS framework because as far as
> I can see most of apps just uses their own styles and markup.
>
>
>> My suggestion would be that we should publicise via this mailing list
>> (and django-users etc) that we are planning to integrate this, and you can
>> use it now via your app. This should hopefully get you more bug reports
>> early and we can merge it in a more finished state for the 1.9 alpha.
>>
>
> That would be great.
>
>  --
> 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/0a3c2428-fe8e-48de-9b25-c658446548a5%40googlegroups.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/CAMwjO1FDmk%3DXZsTiJ5hxJ3utjXW_HCyDu1TKoSRnzwPsv2E13g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Aymeric Augustin]

2015-04-07 17:25 GMT+02:00 Marc Tamlyn :

> The primary questions to establish answers to before a possible merge in
> my opinion are:
> - Do we ship both, or just the new one and release the old one as a third
> party package?
>

I'd like to make the new theme the default unless the developer opts out.

Since the admin CSS and JS receives very little maintenance, keeping the
current theme under django/contrib/admin/classic_theme/static or in a
third-party package doesn't make a significant difference for us.

The former is more convenient for users who choose to opt-out: all they
need is to add 'django.contrib.admin.classic_theme' before
'django.contrib.admin' in INSTALLED_APPS. That will save us some angry
emails ;-)

This leaves the question of how long we keep supporting the classic theme.
I suggest to go for the usual two-releases deprecation cycle and leave it
up to the community to maintain it separately from Django 2.1 on.

My suggestion would be that we should publicise via this mailing list (and
> django-users etc) that we are planning to integrate this, and you can use
> it now via your app. This should hopefully get you more bug reports early
> and we can merge it in a more finished state for the 1.9 alpha.
>

Yes, that's a good idea in any case.

-- 
Aymeric.

-- 
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/CANE-7mWS9gb94jg9XQiR%2BBU9NP4wU4n%2Bvfd9mnfpK0CQK4Tn2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Asif Saifuddin]

How about

a 8 month release cycle and having a LTS in every two years and supporting 
the old LTS atleast 3 years from the release date? there will be 3 version 
between two LTS.

On Thursday, March 12, 2015 at 6:13:11 AM UTC+6, Tim Graham wrote:
>
> With the release of 1.8 coming up, it's time to think about 1.9! I've 
> suggested some dates below. The schedule is similar to the intervals we 
> used for 1.8 with the final release date planned for about 6 months after 
> 1.8 final (barring unforeseen delays, 1.8 will be released about 7 months 
> after 1.7). Please voice any thoughts or concerns. With this schedule it 
> seems that any GSoC work would likely be included in 2.0. If you have any 
> big features planned, please add them here: 
> https://code.djangoproject.com/wiki/Version1.9Roadmap
>
> July 20 - Alpha (feature freeze)
> August 21 - Beta (only release blockers fixed after this)
> September 18 - RC (string freeze for translations)
> October 2 - Final
>

-- 
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/eb57f50b-a07d-4e0f-80a6-7fb845d193d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>
> How about
>
> a 8 month release cycle and having a LTS in every two years and supporting 
> the old LTS atleast 3 years from the release date? there will be 3 version 
> between two LTS.
>

Interesting. I like the idea of having predictable release dates.

-- 
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/33609d33-edc9-4ec1-a324-cdcad74a51f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.