Status of 5.0 release blockers.

Details are available on the Django forum: https://forum.djangoproject.com/t/status-of-5-0-alpha-release/23805 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this grou

Status of 4.2 release blockers.

Details are available on the Django forum: https://forum.djangoproject.com/t/status-of-4-2-release-blockers/18088 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this grou

Re: Status of 4.1 pre-release.

On Thursday, May 12, 2022 at 1:33:38 PM UTC+2 thinkwel...@gmail.com wrote: > > Next step would be someone to pick the preliminary work up and push it > forward. > > I guess I thought the "preliminary work" was already done. There's a > driver written, and a PR for a django backend. > I don't th

Re: Status of 4.1 pre-release.

> Next step would be someone to pick the preliminary work up and push it forward. I guess I thought the "preliminary work" was already done. There's a driver written, and a PR for a django backend. I'd asked [Daniel Varrazzo](https://github.com/dvarrazzo/django-psycopg3-backend/issues/6) if h

Re: Status of 4.1 pre-release.

On Wed, 11 May 2022 at 13:53, thinkwel...@gmail.com < thinkwelldesi...@gmail.com> wrote: > Will the psycopg3 backend > land in time for the 4.1 release? I'm looking forward to it, as it should > support PyPy much better than psycopg2 does. > No. It's

Re: Status of 4.1 pre-release.

Will the psycopg3 backend land in time for the 4.1 release? I'm looking forward to it, as it should support PyPy much better than psycopg2 does. On Wednesday, May 11, 2022 at 3:33:56 AM UTC-4 carlton...@gmail.com wrote: > Hi Jacob. > > I've always

Re: Status of 4.1 pre-release.

Hi Jacob. I've always taken it that the person reviewing will do the marking. (I.e. I don't read it as saying, "Find someone to review it and then mark it RFC yourself", which would contradict the note in the FAQ yes.) #32559 is on my list. IIRC it was there bar a few last tweaks, so I wanted (wa

Re: Status of 4.1 pre-release.

Yes, you shouldn't mark your patches as RFC. * "Better yet, find someone to review your patch and mark the ticket as "Ready for checkin".* Was supposed to mean: *find someone who can review your patch and who will mark the ticket as RFC.* Best, Mariusz -- You received this message because y

Re: Status of 4.1 pre-release.

Hi Carlton, there is somehow a contradiction: In https://code.djangoproject.com/wiki/Version4.1Roadmap it's written: Better yet, find someone to review your patch and mark the ticket as "Ready > for checkin". > but https://docs.djangoproject.com/en/4.0/faq/contributing/#i-m-sure-my-ticket-is-ab

Status of 4.1 pre-release.

Hi all. Time to begin release process for the next major release, Django 4.1! It's been an incredible cycle with (again) a staggering number of contributions. Thank you everyone! The 4.1 feature freeze is scheduled (according to https://code.djangoproject.com/wiki/Version4.1Roadmap) for Tues

Re: Feature Request: customize redirectable status codes in test client

asier if the status codes were a class-level property and given that I've seen this 202 status code plus location header pattern in a few places I figured to ask. It's not an urgent need for me. On Sun, Mar 6, 2022 at 3:59 AM 'Adam Johnson' via Django developers (Contributions

Re: Feature Request: customize redirectable status codes in test client

do. I'm not suggesting to add HTTP 202 as a default > redirectable status code as this would likely break existing tests but > instead to make it easier to subclass the test client by moving the list of > status codes that the test client redirects to a class-level property. The > l

Re: Feature Request: customize redirectable status codes in test client

y what I'd like to do. I'm not suggesting to add HTTP 202 as a default redirectable status code as this would likely break existing tests but instead to make it easier to subclass the test client by moving the list of status codes that the test client redirects to a class-level propert

Re: Feature Request: customize redirectable status codes in test client

- have you tried that? On Sun, 20 Feb 2022 at 04:21, Clemens Wolff wrote: > Hi Django Developers, > > I'd like to discuss a change to the Django test client to enable > customizing the list of status codes that are considered as redirectable > when a GET request is made with `fo

Feature Request: customize redirectable status codes in test client

Hi Django Developers, I'd like to discuss a change to the Django test client to enable customizing the list of status codes that are considered as redirectable when a GET request is made with `follow=True` (see docs in [1]). Specifically, I suggest moving the `redirect_status_codes` proper

Re: Status of 4.0 release blockers.

> Will it be possible to get ticket 32948 > closed and included in 4.0? > I'd be super-glad if that could happen. > We have two partly alternative approaches , so first we need

Re: Status of 4.0 release blockers.

Will it be possible to get ticket 32948 closed and included in 4.0? I'd be super-glad if that could happen. On Monday, September 13, 2021 at 1:04:59 AM UTC-4 Mariusz Felisiak wrote: > Hi y'all, > > Time to begin release process for the next major re

Status of 4.0 release blockers.

Hi y'all, Time to begin release process for the next major release, Django 4.0! The 4.0 feature freeze is scheduled (according to https://code.djangoproject.com/wiki/Version4.0Roadmap) for September 20. We'll probably release the alpha a few days later. We have a few larger patches we want t

Re: Best status to start to contribute

nt. The framework is so big, no-one can take it all on. > > Here a filter for the GeoDjango tickets > <https://code.djangoproject.com/query?status=assigned&status=new&component=GIS&col=id&col=summary&col=status&col=component&col=owner&col=type&col=vers

Re: Best status to start to contribute

Hi Sarah, Welcome! Beyond the “easy pickings”, another good approach is to filter by component. The framework is so big, no-one can take it all on. Here a filter for the GeoDjango tickets <https://code.djangoproject.com/query?status=assigned&status=new&component=GIS&col=id&

Re: Best status to start to contribute

Hi The search linked from the contributing docs is to: https://code.djangoproject.com/query?status=!closed&easy=1 If you uncheck the "assigned" flag you'll find those tickets that have not been claimed by anyone. That said, often tickets are claimed by people, by assigning

Best status to start to contribute

Hi, I'm a new contributor to Django project. I've tried to contribute to a ticket by using the query "easy picking" from the documentation but unfortunately I didn't pay attention to the triage status which is different to the status. Is there a status for easy t

Re: Status of 3.2 release blockers.

I would also lean towards option 3. If someone makes wrappers they might also release them in a third party package. On Wed, 13 Jan 2021 at 17:46, Carlton Gibson wrote: > Hi Paul, > > Thanks for this follow up. To give context, I think there’s enough support > (here and on the PR) to say, OK let

Re: Status of 3.2 release blockers.

Hi Paul, Thanks for this follow up. To give context, I think there’s enough support (here and on the PR) to say, OK let’s take it. Mariusz and I have two others on the list, which we’ll get in tomorrow. I’ll then branch stable/3.2.x (and we can bootstrap Django 4.0 and continue main line developm

Re: Status of 3.2 release blockers.

As we come closer to the deadline, I thought I'd like to bring attention to the one aspect of the zoneinfo-support PR that I am least certain about but which hasn't gotten much discussion, detailed here: https://github.com/django/django/pull/13877#issuecomment-758769902 *Note*: I don't think anyth

Re: Status of 3.2 release blockers.

I agree with Adam. I've also left a small comment on the PR. Paolo On Tue, Jan 12, 2021 at 5:59 PM Adam Johnson wrote: > > I think it's worth merging into 3.2. The change is quite small, the potential > benefits are quite large, and some users live LTS to LTS so could be left > without an opt

Re: Status of 3.2 release blockers.

I think it's worth merging into 3.2. The change is quite small, the potential benefits are quite large, and some users live LTS to LTS so could be left without an option for a long time. I've left some review comments on the PR. On Tue, 12 Jan 2021 at 15:29, Paul Ganssle wrote: > Yeah, sorry I

Re: Status of 3.2 release blockers.

Yeah, sorry I didn't get around to this until so close to the deadline. December was a lot crazier for me than I had hoped. ☹ One thing I'll note is that this PR to allow using zoneinfo timezones is /mostly/ just adding tests. The substantive changes to the codebase are very light, and there shoul

Re: Status of 3.2 release blockers.

Hi all. Paul Ganssle has followed up his earlier PoC PR, and the previous discussion , with a smaller PR in order to *allow* using zoneinfo timezones without an error: Add support for non-pytz zones https://github.com/django/django/p

Re: Status of 3.2 release blockers.

TBH I see Adam has given it the All clear. There should be some way that enough of that adds up to it just getting merged (but I REALLY don't have capacity to think about THAT this week 😀) It's on the list. On Wednesday, 6 January 2021 at 16:46:37 UTC+1 Carlton Gibson wrote: > Hey Nick. > >

Re: Status of 3.2 release blockers.

Hey Nick. Yes, good. 😀 Issue is capacity to look at it. If I can get there I will. Kind Regards, Carlton On Wednesday, 6 January 2021 at 16:01:15 UTC+1 Nick Pope wrote: > Hi Carlton, > > Just wondering if you're still willing to accept the following for 3.2: > >- https://code.djangopro

Re: Status of 3.2 release blockers.

Hi Carlton, Just wondering if you're still willing to accept the following for 3.2: - https://code.djangoproject.com/ticket/16117 - https://github.com/django/django/pull/13532 Adam marked it "ready for checkin" about 6 weeks ago. Cheers, Nick On Wednesday, 6 January 2021 at 10:04:18

Re: Status of 3.2 release blockers.

Hey Florian. OK +1, no problem. > Let me know if I can help somewhere else in exchange ;) Super. On Wednesday, 6 January 2021 at 10:31:54 UTC+1 f.apo...@gmail.com wrote: > Hi Carlton, > > I'd like to put > https://github.com/django/django/pull/12553 > https://github.com/django/django/pull/

Re: Status of 3.2 release blockers.

Hi Carlton, I'd like to put https://github.com/django/django/pull/12553 https://github.com/django/django/pull/13800 onto this list as well. They are imo basically finished and I'd love reviews from our fellows. Let me know if I can help somewhere else in exchange ;) Cheers, Florian On Monday

Status of 3.2 release blockers.

Hi all, Happy New Year! Time to begin release process for the next major release, Django 3.2! Reference: https://code.djangoproject.com/wiki/Version3.2Roadmap The 3.2 feature freeze is scheduled for January 14. We'll probably release the alpha that day. We have a few larger patches we want t

Re: Status of 3.1 release blockers.

Thank you. אורי u...@speedy.net On Fri, Aug 7, 2020 at 8:24 AM Mariusz Felisiak wrote: > > *> After I signed up and logged in, I reverted to Django 3.0, and then one > user was logged out (who should be logged in) and another user got the > exception `Incorrect padding` (from > `base64.b64deco

Re: Status of 3.1 release blockers.

*> After I signed up and logged in, I reverted to Django 3.0, and then one user was logged out (who should be logged in) and another user got the exception `Incorrect padding` (from `base64.b64decode(session_data.encode('ascii'))`). * This is a separate issue, see #31864

Re: Status of 3.1 release blockers.

Hi, Have you tested multiple servers with Django versions 3.0 and 3.1 with `DEFAULT_HASHING_ALGORITHM = 'sha1'`? I created a branch with this setting, with Django 3.1, and then I used it on our staging server. After I signed up and logged in, I reverted to Django 3.0, and then one user was logged

Re: Status of 3.1 release blockers.

Hi Markus, I don't see a clear path to do this, we cannot add a setting that accepts a string and immediately (in the next release) change it to a list, this will require a deprecation path etc. and will be really confusing to users. IMO we can reconsider this new feature in the next releas

Re: Status of 3.1 release blockers.

Can we come up with a way that we have the settings variable around for now, only to allow transitioning, and then add it as a proper feature in 3.2. As for the feature, I think we could choose a path like passlib does: A list of 2 (n>=1) algorithms. The first one will be used for signing, and a

Re: Status of 3.1 release blockers.

It seems that adding DEFAULT_HASHING_ALGORITHM setting is an acceptable solution, we have one remaining question: Do we keep the setting around? 1. we can treat DEFAULT_HASHING_ALGORITHM as a transitional setting, limit its values to `sha1` and `sha256`, and deprecate it immediately. F

Re: Status of 3.1 release blockers.

On Saturday, August 1, 2020 at 12:53:09 PM UTC+2 Florian Apolloner wrote: > And also, how to define this setting to its default value in Django >> versions <= 3.0. >> > > You don't, this is not supported. > Sorry I probably didn't fully understand the question. Either way; this setting is not u

Re: Status of 3.1 release blockers.

On Saturday, August 1, 2020 at 7:16:57 AM UTC+2 Uri wrote: > How do you propose running several versions of Django 3.0 and 3.1 with > this PR and setting? Does it have to be defined, or is it enough using the > default setting? > You have to set it to `sha1` and then when all your instances

Re: Status of 3.1 release blockers.

I also think, when the old hashing algorithm is deprecated, it's better to convert sessions to the new hashing algorithm without logging out users and without raising errors or exceptions. Is it possible? And notice that the Django user may change this setting only in the future, such as in Django

Re: Status of 3.1 release blockers.

Hi Mariusz, How do you propose running several versions of Django 3.0 and 3.1 with this PR and setting? Does it have to be defined, or is it enough using the default setting? And when upgrading Django to 3.1, what is the default setting if this setting is not explicitly defined? And how will it af

Re: Status of 3.1 release blockers.

I like the state of your proposed PR Mariusz. It does add one more setting but it feels like having this configurable project wide will be a plus as it will allow the ecosystem to rely on it and hopefully make audit of large Django application a bit easier when having specific hashing requiremen

Re: Status of 3.1 release blockers.

I've created a draft PR13262 with the new setting for the default hashing algorithm. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this

Re: Status of 3.1 release blockers.

Hey Uri. We’re not going to patch 3.0 now. (Risk of regression is too high — it’s why we have the backporting policy.) It’s 3.1’s job to be “forward compatible” - folks should be able to update. This is a difficult case in that it requires allowing running the old version at the same time as the

Re: Status of 3.1 release blockers.

Hi Carlton, I think a possible solution can be if Django 3.0 will be patched to handle sessions created by 3.1. This will allow both downgrading Django and running Django on several servers with 3.0 and 3.1 in parallel. If this is too late now to do it before releasing 3.1, maybe you can postpone

Re: Status of 3.1 release blockers.

Hi Uri. > On 31 Jul 2020, at 12:11, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote: > > On Fri, Jul 31, 2020 at 12:28 PM Mariusz Felisiak > wrote: > Markus reported a release blocker #31842 > related with running an app on > mu

Re: Status of 3.1 release blockers.

On Fri, Jul 31, 2020 at 12:23 PM Raffaele Salmaso wrote: > On Fri, Jul 31, 2020 at 12:12 PM Carlton Gibson > wrote: > What about: > retry 😅 django 3.1 * add a global settings set to sha1 * configure settings template to use sha256 so a new project will start with new algorithm * add a warning t

Re: Status of 3.1 release blockers.

On Fri, Jul 31, 2020 at 12:34 PM Markus Holtermann wrote: > No, it won't move the problem to 3.2. The problem is that 3.0 only knows > about sha1. 3.1 and later know about sha1 and sha256. Meaning, any > >=3.1,<4.0 version can decode and verify signed data from 4.0 and before. > Sorry, s/3.2/3.1/

Re: Status of 3.1 release blockers.

No, it won't move the problem to 3.2. The problem is that 3.0 only knows about sha1. 3.1 and later know about sha1 and sha256. Meaning, any >=3.1,<4.0 version can decode and verify signed data from 4.0 and before. Cheers Markus On Fri, Jul 31, 2020, at 12:08 PM, Raffaele Salmaso wrote: > On F

Re: Status of 3.1 release blockers.

On Fri, Jul 31, 2020 at 12:12 PM Carlton Gibson wrote: > Yes, perhaps: default to the future sounds better. > What about: django 3.2 * add a global settings set to sha1 * configure settings template to use sha256 so a new project will start with new algorithm * add a warning to sha1 usage and in

Re: Status of 3.1 release blockers.

On Fri, Jul 31, 2020 at 12:28 PM Mariusz Felisiak < felisiak.mari...@gmail.com> wrote: > Markus reported a release blocker #31842 > related with running an app > on multiple servers with different versions of Django (3.0.x or 3.1). > I think it might

Re: Status of 3.1 release blockers.

> I think this just move the migration problem from 3.2 to 4.0. My thought was the instant warning helped with that... BUT... What about the other way: add a migration setting set to new algorithm, so > who really need sha1 can opt-in to old algorithm? > Yes, perhaps: default to the future sound

Re: Status of 3.1 release blockers.

On Fri, Jul 31, 2020 at 11:47 AM Carlton Gibson wrote: > Add the new setting default to sha1. > Raise a DeprecationWarning unless it’s set to sha256 (so folks can opt-in > to the future.) > Remove setting, and change default to sha256, when 4.0? > > Does that sound right? (Grrr.) > I think this j

Re: Status of 3.1 release blockers.

It looks like we need to add the algorithm to the function signatures, as per the PR, but also add a (immediately deprecated) migration setting, so folks can opt-in to the new algorithm when they’re updated. Add the new setting default to sha1. Raise a DeprecationWarning unless it’s set to sha256

Re: Status of 3.1 release blockers.

Thank you for summarizing our IRC discussion, Mariusz. To be clear, the problem occurs during the upgrade process where more than 1 server is involved. That might be the case in small deployments with just 2 servers, where the time of two Django versions running simultaneously is likely small, o

Re: Status of 3.1 release blockers.

Markus reported a release blocker #31842 related with running an app on multiple servers with different versions of Django (3.0.x or 3.1). Signatures created on servers with Django 3.1 are not valid on Django 3.0, it's not only about signing.loads()

Re: Status of 3.1 release blockers.

Hi James, To the first release candidate (July 20) we will backport doc fixes and even cleanups, so you have time to finish this change. Documentation fixes generally are generally more freely backported even to the last release branch. Best, Mariusz -- You received this message because yo

Re: Status of 3.1 release blockers.

I've been working on documentation updates to get the DEP 10 governance listed in the docs, but it's unlikely I'll be able to PR it until this weekend. How do people feel about that also being included in 3.1? It's not exactly a feature change, and it arguably corrects a bug in that the docs as the

Re: Status of 3.1 release blockers.

Hi y'all, The feature freeze was yesterday, so we've branched stable/3.1.x today and Claude has updated the translations catalogs. We're planning to do the alpha release in this week, after fixing two confirmed regressions: https://code.djangoproject.com/ticket/31566 https://code.djangoproject.

Re: Status of 3.1 release blockers.

> > I think we should also address: > > https://code.djangoproject.com/ticket/30678 > > > - GDAL 3 support > > as release blocker, because more and more instal

Re: Status of 3.1 release blockers.

Hi Mariusz, I think we should also address: https://code.djangoproject.com/ticket/30678 - GDAL 3 support as release blocker, because more and more installations will have GDAL 3 by default and the backwards compatibility issues are serious. I'll try to prepare a patch ASAP. As this is only aff

Status of 3.1 release blockers.

Hi y'all, Time to begin release process for the next major release, Django 3.1! The 3.1 feature freeze is scheduled (according to https://code.djangoproject.com/wiki/Version3.1Roadmap) for May 11. We'll probably release the alpha a few days later. We have a few larger patches we want to finish

Re: Status of 3.0 release blockers

Recai, I’m afraid that’s not true. Django 3.0 adds ASGI support for asynchronous calls to the outermost handler. However all the rest of the stack remains synchronous. See the release notes: https://docs.djangoproject.com/en/dev/releases/3.0/ For a single file demo app see my blog post: https://ad

Re: Status of 3.0 release blockers

Hi Carlton , i saw it somewhere , django 3.0 is coming with async database transaction availability . is that right ? 10 Eylül 2019 Salı 11:56:51 UTC+3 tarihinde Carlton Gibson yazdı: > > Hi all. > > Time to begin the release process for 3.0! 🎉 > > The feature freeze was yesterday, with some la

Status of 3.0 release blockers

Hi all. Time to begin the release process for 3.0! 🎉 The feature freeze was yesterday, with some last things making it over the line. Claude has updated the translations catalogs already. Mariusz and Simon have cleaned up the last release blocker this morning, so we've branched stable/3.0

Re: status of 2.2 release blockers

Hi All, Django 2.2rc1 is scheduled for today. There's a single release blocker that just needs a little work: https://github.com/django/django/pull/10978 As such, I'm looking towards Monday at this point. Final release on April 1 should be unaffected. Kind Regards, Carlton -- You recei

Re: status of 2.2 release blockers

These features are in. We're planning to do the alpha release tomorrow. On Sunday, January 13, 2019 at 9:04:29 PM UTC-5, Tim Graham wrote: > > Time to kick off the progress tracker for the next major release! > > The 2.2 feature freeze is scheduled (according to > https://code.djangoproject.com/w

Re: status of 2.2 release blockers

Hi Vaclav, I think current status is "Still work to do" there, so not really... C. On Wednesday, 16 January 2019 17:52:17 UTC+1, Václav Řehák wrote: > > Hi, > > is it possible to get this fix included in 2.2? > > https://github.com/django/django/pull/106

Re: status of 2.2 release blockers

Hi, is it possible to get this fix included in 2.2? https://github.com/django/django/pull/10643 - Fixed #29915 -- Support hyphens in UUIDField filtering Vaclav Dne pondělí 14. ledna 2019 3:04:29 UTC+1 Tim Graham napsal(a): > > Time to kick off the progress tracker for the next major release! >

status of 2.2 release blockers

Time to kick off the progress tracker for the next major release! The 2.2 feature freeze is scheduled (according to https://code.djangoproject.com/wiki/Version2.2Roadmap) for tomorrow, January 14. Typically we've released the alpha a few days later to finish up a few last minutes things. I hav

Re: Installing Channels - bin\\HostX86\\x64\\cl.exe' failed with exit status

er mismatch for actual >> parameter 1 >> src/twisted/internet/iocpreactor/iocpsupport/iocpsupport.c(2537): >> warning C4022: 'PostQueuedCompletionStatus': pointer mismatch for actual >> parameter 1 >> src/twisted/internet/iocpreactor/iocpsupport/iocp

Re: Installing Channels - bin\\HostX86\\x64\\cl.exe' failed with exit status

te.h(209): note: see declaration of '_ts' > src/twisted/internet/iocpreactor/iocpsupport/iocpsupport.c(7642): > error C2039: 'exc_traceback': is not a member of '_ts' > c:\python3.7\include\pystate.h(

Installing Channels - bin\\HostX86\\x64\\cl.exe' failed with exit status

x27;_ts' c:\python3.7\include\pystate.h(209): note: see declaration of '_ts' src/twisted/internet/iocpreactor/iocpsupport/iocpsupport.c(7689): error C2039: 'exc_value': is not a member of '_ts' c:\python3.7\include\pystate.h(209): note: see declarati

Re: Redirect using HTTP status "303 See Other"

I don't think we should make any changes to HttpResponseRedirect, for backwards compatibility reasons if nothing else. It might make sense to encourage people to use HttpResonse(status=303) directly, rather than using subclasses. On Mon, Jun 4, 2018 at 3:51 PM, Duane Hutchins wrote: >

Redirect using HTTP status "303 See Other"

The "302 Found" redirect is used by default in ​django.http.response HttpResponseRedirect. Could we discuss changing this to use "303 See Other" redirects? 303 redirects are more in-line with the intent of the redirect after a change, and also 303 redirects disallow browser caching. If a browse

status of 2.1 release blockers

Time to kickoff the progress tracker for the next major release! The 2.1 alpha is scheduled (according to https://code.djangoproject.com/wiki/Version2.1Roadmap) for today, May 14. Typically we've released the alpha a few days later to finish up a few last minutes things. I have one patch I wa

Re: status of 2.0 release blockers

A few blockers were reported in the past couple days. Patches are completed and being merged shortly. I plan to release Django 2.0 and 1.11.8 tomorrow morning (~12 hours from now). On Thursday, September 21, 2017 at 10:06:11 PM UTC-4, Tim Graham wrote: > > completed today: > https://github.com/d

Re: Status of "Replacing get_absolute_url()"

I added, "This work is abandoned as of 2008. Feel free to continue it if you're intersted in contributing. The Trac ticket is #8264 . " On Thursday, October 12, 2017 at 3:50:36 AM UTC-4, guettli wrote: > > I think this page is outdated: > > https://c

Status of "Replacing get_absolute_url()"

I think this page is outdated: https://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl At the top: > This page is a work in progress - I'm still figuring out the extent of the problem before I start working out a solution. No changes since 8 years. Can someone please update the page?

Re: status of 2.0 release blockers

completed today: https://github.com/django/django/pull/9086 - Refs #28595 -- Added execute wrappers for database queries. I plan to merge this last one early tomorrow, then release the alpha later in the day. https://github.com/django/django/pull/9081 - Fixed #27332 -- Added support for conditi

Re: status of 2.0 release blockers

completed today: https://github.com/django/django/pull/7482 - Simplified URL routing syntax. (code) https://github.com/django/django/pull/9072 - Simplified URL routing syntax. (docs) https://github.com/django/django/pull/9100

Re: status of 2.0 release blockers

Thanks for the feedback. I think the indentation changes are correct, but please leave a comment on the PR so I can be sure which lines you're referring to. I added this text to the release notes per your suggestion: The ``django.conf.urls.url()`` function from previous versions is now availabl

Re: status of 2.0 release blockers

I spent today finishing up writing and then reviewing the documentation for URL routing. I'll give that and the code one more look tomorrow before merging. In the meantime, other reviews (especially from anyone less familiar with the feature) are certainly welcome. https://github.com/django/djan

Re: status of 2.0 release blockers

completed today: https://github.com/django/django/pull/6385 - Fixed #14370 -- Added select2 widget for related object fields in admin. https://github.com/django/django/pull/7611 - Fixed #26608 -- Add support for OVER-clause (window expressions). todo:

status of 2.0 release blockers

Time to kickoff the progress tracker for the next major release! The 2.0 alpha is scheduled (according to https://code.djangoproject.com/wiki/Version2.0Roadmap) for Monday, September 18. Typically we've release the alpha a few days later to finish up a few last minutes things. Here are the PRs

Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

ion. I'll document the http.HTTPStatus solution and add only classes that provide extra functionality for Django-app-plausible status codes. On 7 August 2017 at 16:42, Tim Graham wrote: > I think I prefer documenting Berker's suggestion rather than adding more > classes to Dj

Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

nally I'd be in favour of adding such classes. It seems against the >> > batteries-included philosophy that Django does not provide all of the >> > standard codes as classes. I can never remember which codes correspond >> to >> > which response types, if

Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

-included philosophy that Django does not provide all of the > > standard codes as classes. I can never remember which codes correspond to > > which response types, if I saw status=204 in code it would be a 'magic > > number' for me and I'd have to look it up. HttpRespon

Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

ch response types, if I saw status=204 in code it would be a 'magic > number' for me and I'd have to look it up. HttpResponseRedirect and > HttpResponsePermanentRedirect have been my friends in the past, I can > imagine the same for HttpResponseNoContent. Alternatively,

Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

I would be happy to revisit that decision which was made 9 years ago. APIs returning unusual status codes such as 204 are much more common now than they were then. I can't think of a good reason not to add ~10-15 2-line classes. Marc On 7 April 2017 at 09:37, Brice PARENT wrote: > &g

Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

Personally I'd be in favour of adding such classes. It seems against the batteries-included philosophy that Django does not provide all of the standard codes as classes. I can never remember which codes correspond to which response types, if I saw status=204 in code it would be a 'ma

Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

2 > > with the rationale, "We've decided in the past not to add a new class for > every single response code. You can already pass the status code in when > creating the HttpResponse class, so that can be used in this case." > > (found with this google search: httpresp

Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

Hi, this was already wontfixed here: https://code.djangoproject.com/ticket/3362 with the rationale, "We've decided in the past not to add a new class for every single response code. You can already pass the status code in when creating the HttpResponse class, so that can be used in

[feature request] including HttpResponse(status=204) as an HttpResponse subclasses

found HttpResponse(status=204) <https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10> may come for rescue in this case, thus it would be better to include HttpResponse(status=204) as an HttpResponse subclasses for convenience so that could save Django users from asking those ret

Re: status of 1.11 release blockers

re on track to issue the release candidate on Monday. > > [0] > https://code.djangoproject.com/query?status=!closed&severity=Release%20blocker&desc=1&order=changetime > > On Saturday, February 11, 2017 at 5:14:34 PM UTC-5, Tim Graham wrote: >> >> Thank you

Re: status of 1.11 release blockers

A handful of blockers (mostly in the final stages) remain as of right now [0]. We're on track to issue the release candidate on Monday. [0] https://code.djangoproject.com/query?status=!closed&severity=Release%20blocker&desc=1&order=changetime On Saturday, February 11, 2017 at

  1   2   3   4   5   6   7   >