New related_name triggering migrations for all plugins

It appears that this commit changed how the related_name is calculated per CMSPlugin subclass. If I do ./manage.py makemigrations, it attempts to create migrations for any installed app which subclasses CMSPlugin:

$ ./manage.py makemigrations
Migrations for 'cmsplugin_filer_image':
  0009_auto_20160719_0239.py:
    - Alter field cmsplugin_ptr on filerimage
Migrations for 'cmsplugin_filer_file':
  0005_auto_20160719_0239.py:
    - Alter field cmsplugin_ptr on filerfile
Migrations for 'djangocms_inherit':
  0003_auto_20160719_0239.py:
    - Alter field cmsplugin_ptr on inheritpageplaceholder
Migrations for 'cmsplugin_filer_teaser':
  0003_auto_20160719_0239.py:
    - Alter field cmsplugin_ptr on filerteaser
Migrations for 'cmsplugin_filer_folder':
  0003_auto_20160719_0239.py:
    - Alter field cmsplugin_ptr on filerfolder

As far as I can tell, the only thing these migrations do is add the related_name attribute to the cmsplugin_ptr field.

I didn’t see any warning about this in the documentation and I don’t see bugs or recent migrations added to other projects (cmsplugin_filer_*, etc.) so my first suspicion is that I’ve goofed something up or am generally suffering from lack of sleep. Apologies if so!

If this is a legitimate bug, this seems to mean that every external plugin app needs to have a new migration added and possibly will need to have point releases that are pinned to django-cms>=3.3.1. I haven’t tested, but if these migrations are added to a plugin app that is then run on django-cms<3.3.1, won’t migrations detect the lack of a related_name attribute and want to create a migration to remove it?

[czpython]

Closing as this has now been addressed in all major addons.

[ericamador]

@czpython

So far we think the best approach is to create the migration for apps that support 3.3.0 and up meaning Django 1.8+ (cmsplugin-filer is an example). For apps that still support Django 1.6 and 1.7, we’re planning to either drop 1.6 & 1.7 support or simply add the parent link field explicitly to the plugin model and specify the old related_name.

Since this was introduced in the 3.3.1 release, shouldn’t there a note in the changelog for v3.3.1 that mentions that this is to be expected? My organization maintains about 10 different CMS plugins, and to see that a new migration must be made for all of them because of what might appear at first glance to be a (semver) patch release was a little jarring. At first, I thought this was a problem with our configuration because there was no note of this in the changelog.