This might be a solution for projects which wish to upgrade in advance of their dependencies but as you note its implications for future app upgrades are unclear.
This still doesn't provide an answer for app developers. The deprecation timeline says migrations aren't required until 2.0. But if your app depends on contrib.auth it will be required in 1.7 based on this previous note. As best I can tell, supporting Django < 1.7 + South and Django 1.7+ requires making a backwards incompatible release of the app. That's fine if that is the only way forward but I think the community could use more guidance on this. On Tuesday, June 17, 2014 10:06:11 AM UTC-4, Tim Graham wrote: > > I'm sure Andrew will have more info, but you could use MIGRATION_MODULES > and generate migrations for any 3rd party apps that don't have them. I'm > not sure how the transition when the app starts shipping its own migrations > will go. > > On Tuesday, June 17, 2014 9:18:57 AM UTC-4, Mark Lavin wrote: >> >> Hello, >> >> I noticed some changes over the past few days to the migrations and I was >> concerned about how this could impact reusable applications planning to >> support 1.7. >> In particular there is a note in >> https://docs.djangoproject.com/en/1.7/topics/migrations/#dependencies >> >> Be aware, however, that unmigrated apps cannot depend on migrated apps, >> by the very nature of not having migrations. This means that it is not >> generally possible to have an unmigrated app have a ForeignKey or >> ManyToManyField to a migrated app; some cases may work, but it will >> eventually fail. >> >> >> Given that contrib.auth now has migrations and many reusable applications >> have FKs to the User model, doesn't this force most reusable applications >> to ship migrations >> in order to be compatible with 1.7? Is this an unintended consequence or >> an expected requirement? I know the plan is to eventually require >> migrations but this >> seems like a hard requirement which could make upgrading to 1.7 more >> difficult due to lagging dependencies. >> >> Is there an acceptable approach for a reusable application to support 1.6 >> + South and 1.7 + db.migrations? This >> http://treyhunner.com/2014/03/migrating-to-django-1-dot-7/ seemed >> like a good approach though it does highlight the backwards compatibility >> issues. >> >> Best, >> >> Mark >> > -- You received this message because you are subscribed to the Google Groups "Django developers" 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/ec0ab6f4-5aa7-4784-9a17-e957696268f5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
