Running makemigrations yields file number 0001 if the app's latest migration has a number-only filename

[Kendall Gifford]

For some time we've successfully used the convention of having our migration files only include the migration number in the filename: 0001_initial.py, 0002.py, 0003.py, etc. This currently works with Django 1.8 with the exception of the makemigrations command. When creating a new migration in this situation, it will always give the new migration file the number 0001.

$ ls apps/foobar/migrations/
0001_initial.py  0002.py  0003.py __init__.py
$ python manage.py makemigrations foobar
Migrations for 'foobar':
  0001_widget_foobar.py:
    - Add field foobar to widget

The expectation I'd have is for the newly created file to have been named 0004_widget_foobar.py (0004 instead of 0001) regarless of the fact that 0003.py has no "name" component. This isn't a huge issue, since we always end up renaming the file to only include the number anyway, but it'd be easier and less error prone if the generated number were at least already correct.

I know that this bug is caused by the implementation of django.db.migrations.autodetector.MigrationAutoDetector.parse_number which always assumes files will be named: ^\d+_ which isn't always the case. The rest of the migration infrastructure supports our number-only filename convention just fine, which is why I consider this a bug instead of a feature request.

[Tim Graham]

I guess we could change the regex to end on a non-numeric character instead.

[Caio Ariede]

​https://github.com/django/django/pull/5128

[Tim Graham <timograham@…>]

In de41fbb:

Fixed #25239 -- Corrected makemigrations numbering if a migration has a number-only filename.