Here's the status on blockers. Given the work that remains, I don't foresee the beta release happening earlier than Wednesday, but the next update of this thread will be tomorrow.
#24324 <https://code.djangoproject.com/ticket/24324> Crashes when project path or path to Django install contains a non-ascii character <https://code.djangoproject.com/ticket/24324> Owner: Tim Status: Patch needs review #24351 <https://code.djangoproject.com/ticket/24351> RunPython/RunSQL operations in contrib migrations and multi-db routers. <https://code.djangoproject.com/ticket/24351>Owner: Loic Status: API design decision needed. Time permitting, Loic will write to the mailing list on this tomorrow. #24328 <https://code.djangoproject.com/ticket/24328> The new Options._get_fields() method needs to be cleaned up <https://code.djangoproject.com/ticket/24328> Owner: Anssi Status: Anssi still reviewing the patch; decision may be needed on backwards compatibility of get_fields(). #24343 <https://code.djangoproject.com/ticket/24343> UUID foreign key accessor returns inconsistent type <https://code.djangoproject.com/ticket/24343>Owner: Marc/Josh/Shai Status: Josh working on cleaning up the patch. Review/feedback from Anssi requested. #24291 <https://code.djangoproject.com/ticket/24291> Migrations fail with unused swappable model <https://code.djangoproject.com/ticket/24291> Owner: Markus Status: Patch looks good to me; Markus to review & commit tomorrow. On Monday, February 16, 2015 at 11:12:46 AM UTC-5, Tim Graham wrote: > > There are still quite a few unresolved issues, so the beta release won't > happen today. I'll send an update at the end of the day with the status of > the remaining issues. > > On Friday, February 13, 2015 at 1:30:44 PM UTC-5, Markus Holtermann wrote: >> >> Hey folks, >> >> I looked into the issues #24225, #24264 and #24282 and have a working >> pull request ready for review: https://github.com/django/django/pull/4097 >> >> The essential change in the pull request is the way how the set of models >> that needs to be rerendered is constructed. Instead of naively only >> resolving one level of relations (Only rerender B and C if C changed: A --> >> B --> C) the new approach recursively checks for relational fields >> (forwards and reverse relations (e.g. ForeignKey and ManyToManyRel)) as >> well as inheritance. >> >> This approach boils down to the following behavior: >> >> If a completely standalone model (no incoming or outgoing relations and >> no subclasses and only a directed subclass of models.Model) changes, only >> this model will be rerendered, which is the best case scenario. If every >> model is somehow related (directly or through other models) to every other >> model, e.g. through the user model, changing one model from that set will >> require *all* models to be rerendered, which is the worst case scenario >> and results in the similar behavior as 1.7. >> >> To get that pull request into the 1.8 beta I ask everybody to take a look >> and try it out on their projects. Especially if 1.8 alpha 1 didn't work for >> you. >> >> Thanks >> >> /Markus >> >> On Saturday, December 20, 2014 at 8:40:33 PM UTC+1, Tim Graham wrote: >>> >>> As we approach the date for 1.8 alpha, I plan to send a weekly update on >>> the status of release blocking issues. >>> >>> We currently have 3 release blockers affecting master. You can use this >>> Trac filter to see them: >>> >>> https://code.djangoproject.com/query?status=assigned&status=new&version=master&severity=Release+blocker >>> >>> You can also see other tickets we are targeting for 1.8 with this >>> filter. This includes some of the remaining large features as well as a >>> couple code reorganizations we want to make closer to when cut the 1.8 >>> branch to avoid creating conflicts with the large features that are in >>> progress. >>> >>> https://code.djangoproject.com/query?status=assigned&status=new&keywords=~1.8-alpha >>> >>> Here is a summary of where we stand with each release blocker: >>> >>> #23861 - >>> <https://code.djangoproject.com/ticket/23861> Fields referenced in >>> migrations cannot be (re)moved, even if migrations have been squashed >>> <https://code.djangoproject.com/ticket/23861> Owner: ? >>> Status: We need someone to investigate a strategy for how we can >>> deprecate model fields while keeping them available in historical >>> migrations. Any takers? If we cannot complete this, I propose we bump the >>> deprecation of IPAddressField until the issue is solved. >>> >>> #22340 - >>> <https://code.djangoproject.com/ticket/22340> Legacy Table Creation >>> Methods Not Properly Deprecated >>> <https://code.djangoproject.com/ticket/22340> Owner: Claude >>> Status: This issue is being discussed in the thread "Migrations in >>> Django 1.7 make unit testing models harder". In short, we likely to need to >>> solve the performance issues with migrations before we can proceed with the >>> deprecation. If we cannot, we'll likely have to delay the deprecation. >>> >>> #23271 - <https://code.djangoproject.com/ticket/23271>Makemessages can >>> corrupt existing .po files on Windows >>> <https://code.djangoproject.com/ticket/23271> >>> Owner: Ramiro >>> Status: Ramiro said he would have some time to investigate the issue >>> soon. >>> >> -- 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 [email protected]. To post to this group, send email to [email protected]. 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/28e86cd2-8ae5-4dd2-adf5-2340b060bbc1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
