Re: Django versioning and breaking changes policy

[Aymeric Augustin]

Django doesn't transition to semver.

It keeps its own versioning scheme but reuses some good ideas from semver.

-- 
Aymeric.



> On 5 Apr 2017, at 00:29, Bernhard Posselt  wrote:
> 
> Oh wow, haven't seen that yet, thank you :)
> 
> Just make sure to follow the semver spec closely if you transition to
> semver, because it can cause issues for parsers. Also the spec is more
> restrictive than you'd think with regards to syntax (source: working
> with semver in my current Django project)
> 
> 
> On 04/04/2017 11:11 PM, Aymeric Augustin wrote:
>> Hello,
>> 
>> As far as I can tell, recent modifications to the release process means it 
>> will meet your expectations going forwards.
>> 
>> Take a look at 
>> https://docs.djangoproject.com/en/dev/internals/release-process/ 
>>  for 
>> details.
>> 
>> Best regards,
>> 
> 
> -- 
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/4dc89ce1-4e93-a7c0-c3a7-b464a889e6ca%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/233FC97C-A042-42FF-B6DE-744BC7904ACB%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: proposal: add special subclass of ForeignKey for storing ContentTypes

[Asif Saifuddin]

Hi Sergey,

I was also wondering why GenericForeignKey don't have direct subclass of 
ForeignKey while writing a dep about field API improvement. Though I am not 
100% sure your implementation.

Thanks for bringing it up.



On Wednesday, April 5, 2017 at 2:46:31 AM UTC+6, Sergey Fedoseev wrote:
>
> Hi all,
>
> Some time ago I created 'new feature` ticket 
>  and Tim Graham asked me to 
> write here to get some feedback on the idea. So here it is.
>
> ContentType model is quite specific, so we could add the subclass of 
> ForeignKey with some specific features.
>
>
> For example, we have a model:
>
>
> class ModelWithContentType(models.Model):
> ct = ContentTypeField(on_delete=models.CASCADE)
>  
>
> In comparison with ForeignKey ContentTypeField will have these features:
>
>1. ModelWithContentType.objects.first().ct will use content types 
>cache 
>
>
>1. ContentTypeField will support lookups on the model classes (on 
>model instances too?):
>
> ModelWithContentType.objects.filter(ct=FooModel) vs.
>
>
> ModelWithContentType.objects.filter(ct=ContentType.objects.get_for_model(FooModel))
>
>
> ModelWithContentType.objects.filter(ct__in=[FooModel, BarModel]) vs.
> ModelWithContentType.objects.filter(ct__in=[ContentType.objects.get_for_model(model)
>  
> in [FooModel, BarModel]])
>
>1. Creation using a model class as a value (not sure if it's useful 
>actually): 
>
> ModelWithContentType.objects.create(ct=FooModel)
>
>
> Here's ​rough implementation 
> .
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0764f9bc-be05-47ac-8201-b419a93d3061%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pull requests waiting for review

[Josh Smeaton]

I'd just like to add - thank you for the polite reminder! I know it can be 
very frustrating having patches sit around without any attention, and 
sometimes a good bump is and/or feels necessary. Doing so in a positive 
manner is very welcome.

As a small reminder - the release of django 1.11 happened today, and a lot 
of people have been busy preparing for that release (as well as the 
security releases that went out today) for some time. It's likely that more 
attention will be spent reviewing contributions moving forward.

On Wednesday, 5 April 2017 04:56:02 UTC+10, Anton Samarchyan wrote:
>
> Hello,
>
> I have several PRs which have been completed but haven't been entirely 
> reviewed/accepted yet. Some of them are haven't been reviewed for over a 
> month. So this is just a reminder. Here's a full lists of all my commits 
> which pass all of the tests and have no conflicts:
>
>- https://github.com/django/django/pull/8227
>- https://github.com/django/django/pull/8208
>- https://github.com/django/django/pull/8202
>- https://github.com/django/django/pull/8160
>- https://github.com/django/django/pull/7799
>
> Thank you.
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/004afd6c-3668-4033-9848-96f22d8b30c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django versioning and breaking changes policy

[Curtis Maloney]

See? This is exactly what I told you you could expect ... to be shown 
the new release process details :)


[For those playing at home, Bernhard raised this concern on IRC first, 
and I recommended bringing it here.  He expressed concern about being 
roasted, and I predicted someone would introduce him to the details of 
the new release process :)]


--
C

On 05/04/17 08:29, Bernhard Posselt wrote:

Oh wow, haven't seen that yet, thank you :)

Just make sure to follow the semver spec closely if you transition to
semver, because it can cause issues for parsers. Also the spec is more
restrictive than you'd think with regards to syntax (source: working
with semver in my current Django project)


On 04/04/2017 11:11 PM, Aymeric Augustin wrote:

Hello,

As far as I can tell, recent modifications to the release process means it will 
meet your expectations going forwards.

Take a look at https://docs.djangoproject.com/en/dev/internals/release-process/ 
 for details.

Best regards,





--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bd9bbe2b-79db-a765-9b4a-7f4afd9901a4%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Django versioning and breaking changes policy

[Bernhard Posselt]

Oh wow, haven't seen that yet, thank you :)

Just make sure to follow the semver spec closely if you transition to
semver, because it can cause issues for parsers. Also the spec is more
restrictive than you'd think with regards to syntax (source: working
with semver in my current Django project)


On 04/04/2017 11:11 PM, Aymeric Augustin wrote:
> Hello,
>
> As far as I can tell, recent modifications to the release process means it 
> will meet your expectations going forwards.
>
> Take a look at 
> https://docs.djangoproject.com/en/dev/internals/release-process/ 
>  for 
> details.
>
> Best regards,
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4dc89ce1-4e93-a7c0-c3a7-b464a889e6ca%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django versioning and breaking changes policy

[Bernhard Posselt]

Hi Tobias,

my impression is that as a developer you can keep up with the changes
pretty well and I don't think it's related to features being too costly
to address. The main issue is really third-party code.

The only thing that I can currently think of as a comparison is the
Angular 1.x branch: If there were breaking changes then there were very
few and I don't think I've ever had issues with third-party plugins
breaking due to upgrading an Angular 1.x release to a new "major"
version. Yeah, I know that it's probably hard to compare the two
frameworks and they rewrote everything from scratch in v2 and basically
broke all code, but the 1.x parts were pretty well done at least :)

Thinking about it I think the main issue is probably the high number of
breaking interfaces: it's not like a bump from 1.10 to 1.11 changes two
interfaces but it's a whole array of things in all kinds of components.
This makes it very likely that an extension is affected by a breaking
change.

In addition to that I kinda feel like when using Django nowadays I can't
really use it "as is", out of the box. 5-7 years ago when webdevelopment
was about serverside templating & forms and very little JavaScript
Django was almost perfect and you needed maybe 1 or 2 third-party libs
to create a full website. Nowadays you need REST apis (DRF, CORS
middleware) and also want to employ a CSP to lock things down.

So TL;DR I suppose:

* web development got more complex
* Django did not move fast enough (IMHO) to support "modern" websites,
responsibilities were moved to third-party libs
* you therefore need more third-party libs which are usually (there are
ofc exceptions) maintained worse than Django
* there are a lot of breaking changes in interfaces each release so
upgrading hurts a lot

I know its a difficult problem so I don't know what the solution
could/should be and I'm interested in opinions :)

On 04/04/2017 11:43 PM, Tobias McNulty wrote:
> Hello Bernhard,
>
> In my experience, Django strikes a good balance between adding new features
> without moving so quickly that it's impossible to keep up. That being said,
> third-party packages *can* vary widely in the speed with which they add
> support for new Django versions after a new major release.
>
> What are some changes in Django over the past few releases that you felt
> were too significant or costly to address?
>
> Tobias
>
> On Tue, Apr 4, 2017 at 3:15 PM, Bernhard Posselt 
> wrote:
>
>> Hi guys :)
>>
>> I'm maintaining a Django project that uses 6 apps:
>>
>> * djangorestframework,
>>
>> * django-parler (database translations),
>>
>> * django-allauth (openid & richer account settings)
>>
>> * django-recaptcha2 (simple recaptcha widget)
>>
>> * django-csp
>>
>> * django-cors-middleware
>>
>> Each time a new Django version is published it takes me at least a few
>> weeks to upgrade. The reason is that each release breaks something in
>> the apps that I use. Code that I wrote myself can usually be fixed
>> pretty quickly.
>>
>> Personally I don't think that the number of dependencies is excessive.
>> Furthermore I think that Django developers want to offload as much
>> functionality as possible to thirdparty apps to improve maintainability
>> so I doubt that I'm the only one with these issues.
>>
>> I know that deprecating and cleaning up things is *very* important to
>> keep the framework alive however was it ever considered to tune down the
>> frequency of breaking changes (like only remove features in a new LTS
>> release)?
>>
>> Apart from that would it be possible to adopt semver? If you had
>> followed semver closely, each 1.x release would have actually been a
>> major release (e.g. 1.1 -> 2.0.0, 1.2 -> 3.0.0) and your point releases
>> would need to contain three version numbers (e.g. 1.11.0 and not 1.11).
>>
>> I know that this versioning approach leads to very high version number
>> in a short amount of time but that's essentially what Django does:
>> breaking compat with each release :)
>>
>>
>>
>> --
>> 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-developers/7fde82bd-352d-9946-2cbc-699f04bd8773%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.co

Re: Django versioning and breaking changes policy

[Tobias McNulty]

Hello Bernhard,

In my experience, Django strikes a good balance between adding new features
without moving so quickly that it's impossible to keep up. That being said,
third-party packages *can* vary widely in the speed with which they add
support for new Django versions after a new major release.

What are some changes in Django over the past few releases that you felt
were too significant or costly to address?

Tobias

On Tue, Apr 4, 2017 at 3:15 PM, Bernhard Posselt 
wrote:

> Hi guys :)
>
> I'm maintaining a Django project that uses 6 apps:
>
> * djangorestframework,
>
> * django-parler (database translations),
>
> * django-allauth (openid & richer account settings)
>
> * django-recaptcha2 (simple recaptcha widget)
>
> * django-csp
>
> * django-cors-middleware
>
> Each time a new Django version is published it takes me at least a few
> weeks to upgrade. The reason is that each release breaks something in
> the apps that I use. Code that I wrote myself can usually be fixed
> pretty quickly.
>
> Personally I don't think that the number of dependencies is excessive.
> Furthermore I think that Django developers want to offload as much
> functionality as possible to thirdparty apps to improve maintainability
> so I doubt that I'm the only one with these issues.
>
> I know that deprecating and cleaning up things is *very* important to
> keep the framework alive however was it ever considered to tune down the
> frequency of breaking changes (like only remove features in a new LTS
> release)?
>
> Apart from that would it be possible to adopt semver? If you had
> followed semver closely, each 1.x release would have actually been a
> major release (e.g. 1.1 -> 2.0.0, 1.2 -> 3.0.0) and your point releases
> would need to contain three version numbers (e.g. 1.11.0 and not 1.11).
>
> I know that this versioning approach leads to very high version number
> in a short amount of time but that's essentially what Django does:
> breaking compat with each release :)
>
>
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/django-developers/7fde82bd-352d-9946-2cbc-699f04bd8773%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMGFDKRDPBk9CSMe%3DOE-xN1zBTkya6rxWzabvnEQWPe4-GhOBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django versioning and breaking changes policy

[Aymeric Augustin]

Hello,

As far as I can tell, recent modifications to the release process means it will 
meet your expectations going forwards.

Take a look at https://docs.djangoproject.com/en/dev/internals/release-process/ 
 for details.

Best regards,

-- 
Aymeric.

PS - https://twitter.com/fwiles/status/849161016734830592 

> On 4 Apr 2017, at 21:15, Bernhard Posselt  wrote:
> 
> Hi guys :)
> 
> I'm maintaining a Django project that uses 6 apps:
> 
> * djangorestframework,
> 
> * django-parler (database translations),
> 
> * django-allauth (openid & richer account settings)
> 
> * django-recaptcha2 (simple recaptcha widget)
> 
> * django-csp
> 
> * django-cors-middleware
> 
> Each time a new Django version is published it takes me at least a few
> weeks to upgrade. The reason is that each release breaks something in
> the apps that I use. Code that I wrote myself can usually be fixed
> pretty quickly.
> 
> Personally I don't think that the number of dependencies is excessive.
> Furthermore I think that Django developers want to offload as much
> functionality as possible to thirdparty apps to improve maintainability
> so I doubt that I'm the only one with these issues.
> 
> I know that deprecating and cleaning up things is *very* important to
> keep the framework alive however was it ever considered to tune down the
> frequency of breaking changes (like only remove features in a new LTS
> release)?
> 
> Apart from that would it be possible to adopt semver? If you had
> followed semver closely, each 1.x release would have actually been a
> major release (e.g. 1.1 -> 2.0.0, 1.2 -> 3.0.0) and your point releases
> would need to contain three version numbers (e.g. 1.11.0 and not 1.11).
> 
> I know that this versioning approach leads to very high version number
> in a short amount of time but that's essentially what Django does:
> breaking compat with each release :)
> 
> 
> 
> -- 
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/7fde82bd-352d-9946-2cbc-699f04bd8773%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/D5E11913-A10C-4F76-AD8B-59E95EB1144F%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Django versioning and breaking changes policy

[Bernhard Posselt]

Hi guys :)

I'm maintaining a Django project that uses 6 apps:

* djangorestframework,

* django-parler (database translations),

* django-allauth (openid & richer account settings)

* django-recaptcha2 (simple recaptcha widget)

* django-csp

* django-cors-middleware

Each time a new Django version is published it takes me at least a few
weeks to upgrade. The reason is that each release breaks something in
the apps that I use. Code that I wrote myself can usually be fixed
pretty quickly.

Personally I don't think that the number of dependencies is excessive.
Furthermore I think that Django developers want to offload as much
functionality as possible to thirdparty apps to improve maintainability
so I doubt that I'm the only one with these issues.

I know that deprecating and cleaning up things is *very* important to
keep the framework alive however was it ever considered to tune down the
frequency of breaking changes (like only remove features in a new LTS
release)?

Apart from that would it be possible to adopt semver? If you had
followed semver closely, each 1.x release would have actually been a
major release (e.g. 1.1 -> 2.0.0, 1.2 -> 3.0.0) and your point releases
would need to contain three version numbers (e.g. 1.11.0 and not 1.11).

I know that this versioning approach leads to very high version number
in a short amount of time but that's essentially what Django does:
breaking compat with each release :)



-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7fde82bd-352d-9946-2cbc-699f04bd8773%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

proposal: add special subclass of ForeignKey for storing ContentTypes

[Sergey Fedoseev]

Hi all,

Some time ago I created 'new feature` ticket 
 and Tim Graham asked me to 
write here to get some feedback on the idea. So here it is.

ContentType model is quite specific, so we could add the subclass of 
ForeignKey with some specific features.


For example, we have a model:


class ModelWithContentType(models.Model):
ct = ContentTypeField(on_delete=models.CASCADE)
 

In comparison with ForeignKey ContentTypeField will have these features:

   1. ModelWithContentType.objects.first().ct will use content types cache 


   1. ContentTypeField will support lookups on the model classes (on model 
   instances too?):

ModelWithContentType.objects.filter(ct=FooModel) vs.

ModelWithContentType.objects.filter(ct=ContentType.objects.get_for_model(FooModel))


ModelWithContentType.objects.filter(ct__in=[FooModel, BarModel]) vs.
ModelWithContentType.objects.filter(ct__in=[ContentType.objects.get_for_model(model)
 
in [FooModel, BarModel]])

   1. Creation using a model class as a value (not sure if it's useful 
   actually): 

ModelWithContentType.objects.create(ct=FooModel)


Here's ​rough implementation 
.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7a1bcdcf-bd6c-4258-b0dc-a98492493a53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pull requests waiting for review

[Aymeric Augustin]

Hello,

A few years ago, a 5-for-1 deal was set up: if you review five patches or 
tickets, a core dev reviews a patch or ticket of your choice. I abused that 
system to get a dozen patches reviewed before I joined the team :-)

Later I volunteered for the other side of the deal. It hasn't been used for 
some time, but as far as I'm concerned, it's still valid. Show me a list of 5 
pull requests or tickets which you're reviewed or triaged and I'll review any 
of these PRs!

I hope this helps,

-- 
Aymeric.



> On 4 Apr 2017, at 20:56, Anton Samarchyan  wrote:
> 
> Hello,
> 
> I have several PRs which have been completed but haven't been entirely 
> reviewed/accepted yet. Some of them are haven't been reviewed for over a 
> month. So this is just a reminder. Here's a full lists of all my commits 
> which pass all of the tests and have no conflicts:
> https://github.com/django/django/pull/8227
> https://github.com/django/django/pull/8208
> https://github.com/django/django/pull/8202
> https://github.com/django/django/pull/8160
> https://github.com/django/django/pull/7799
> Thank you.
> 
> -- 
> 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 https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/1ae0558c-f50d-4279-891e-a80369b49be1%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/FB18F020-C789-44D7-AE8A-5B34496BEDB5%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Pull requests waiting for review

[Anton Samarchyan]

Hello,

I have several PRs which have been completed but haven't been entirely 
reviewed/accepted yet. Some of them are haven't been reviewed for over a 
month. So this is just a reminder. Here's a full lists of all my commits 
which pass all of the tests and have no conflicts:

   - https://github.com/django/django/pull/8227
   - https://github.com/django/django/pull/8208
   - https://github.com/django/django/pull/8202
   - https://github.com/django/django/pull/8160
   - https://github.com/django/django/pull/7799
   
Thank you.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1ae0558c-f50d-4279-891e-a80369b49be1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django 1.11 released

[Tim Graham]

Django 1.11, the next long-term support release, is now available:

https://www.djangoproject.com/weblog/2017/apr/04/django-111-released/

With the release of Django 1.11, Django 1.10 has reached the end of 
mainstream support. The final minor bugfix release (1.10.7) was issued 
today. Django 1.10 will receive security and data loss fixes for another 
eight months until December 2017.

Django 1.9 has reached the end of extended support. The final security 
release (1.9.13) was issued today. All Django 1.9 users are encouraged to 
upgrade to Django 1.10 or later.

See the downloads page [1] for a table of supported versions and the future 
release schedule.

[1] https://www.djangoproject.com/download/#supported-versions

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0e767d3c-da7b-42ab-b053-e186bd2ed1b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django security releases issued: 1.10.7, 1.9.13, and 1.8.18

[Tim Graham]

Today the Django team issued 1.10.7, 1.9.13, and 1.8.18 as part of our 
security process. These releases address two security issues, and we 
encourage all users to upgrade as soon as possible:

https://www.djangoproject.com/weblog/2017/apr/04/security-releases/

As a reminder, we ask that potential security issues be reported via 
private email to secur...@djangoproject.com and not via Django's Trac 
instance or the django-developers list. Please see 
https://www.djangoproject.com/security for further information.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cb5fc51e-266b-456c-aaa6-8bf78874cac4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

[David Evans]

Hi Aleksej,

Thanks for your work on this, and sorry I haven't replied sooner -- just 
been busy with lots of other things ;)

My plan for integrating WhiteNoise was actually to merge it in as part of 
contrib.staticfiles and basically stop development on it as an independent 
project. When I first started WhiteNoise I went to quite a lot of effort to 
make the core framework-agnostic and to have all the Django specific code 
as an extension to the core. However this makes the code more complex than 
if it was written for Django alone. I'm also not sure it gets a lot of use 
outside of the Django world as other frameworks have their own way of doing 
things and the most useful features of WhiteNoise are Django only.

So the end-goal in my mind is to have a stripped down and simplified 
version of the WhiteNoise code bundled as part of Django itself, which I 
could then help maintain as part of the wider Django project. However, I 
don't think this process would be an ideal project for someone who is a new 
contributor to Django as it would require quite a detailed understanding of 
the design decisions and architectural tradeoffs behind WhiteNoise. Really 
this is the sort of thing I ought to be doing but it's been quite a busy 
year (new baby, work, etc etc) and I just haven't had the time.

If you're able to bundle WhiteNoise as it currently is with Django in a way 
that the core devs are happy with then that's great, and obviously I 
wouldn't stand in your way. But I can imagine that there might be some 
resistance to creating a hard dependency on WhiteNoise, while it's still a 
standalone project.

Again, thanks for the work you've put into this and sorry I don't have a 
more helpful response.

Dave

On Wednesday, 22 March 2017 16:14:58 UTC, Aleksej Manaev wrote:
>
> Am I on the right track with the integration of WhiteNoise into Django? 
> Can Someone lead me to the next steps that need to be done?
>
>
> https://github.com/django/django/compare/master...AleksejManaev:ticket_27325?expand=1
>
> I think "django/views/static.py" can't be deprecated because it is used 
> for providing MEDIA_FILES during development and WhiteNoise is only 
> responsible for STATIC_FILES.
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cfbf04a4-9346-4fd7-95bf-e3802f7a8e5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.