Hey Tim, thanks for the collection of tasks that have to be done for 1.8.
Especially wrt #23861 and #23891 I just realized that, since 1.8 is an LTS release, we'd need to support and that field (and related changes) until 2018. That's Django 2.2/2.3 I guess. Considering the ideas that exists to tackle that problem, I'm almost certain the backporting overhead required for fixes is huge once the code is removed from the general releases. I'm not sure about #22340, though, but I wouldn't be surprised if that's the same. I don't think we should consider delaying the deprecation to 2.0 or later. From my perspective this has to be fixed and decided for 1.8. Otherwise we are going to make our life a living hell. I'm happy to assist and answer questions, but I don't have the time to completely work out and write down a solution. /Markus On Saturday, December 20, 2014 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/5abfe5b8-4f2a-4982-b97a-529c0cd2c9cb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
