Change labels and transitions attr name, etc

[andreif]

...use enum instead of int in field value; raise validation error when enum is not found by value or name (and support digit str), etc

WARNING: Inconsistent field value atm -- enum for Django 1.8 and int for other versions when model is initialized

[fcurella]

i think it would be totally fine to drop django 1.5 and django 1.6

[andreif]

We have some projects still running on Django 1.1 😨 Not sure where the border is

[fcurella]

I'm not entirely convinced we should worry that much about backward-compatibility -- as long as we version correctly (ie: increment the Major version) and provide a documented upgrade path

[fcurella]

I would keep the env vars specified as they currently are, just in case there's going to be a 1.9.99

[andreif]

We can always pad another 9 😺

[fcurella]

Does the DJANGO="Django>=1.8,<1.9" have any drawbacks? I'd rather have something consistently reliable, instead of a possible time bomb to patch in the future

[andreif]

It's harder to read and exclude. Will the shorter version fail in some cases?

[fcurella]

A correct statement is that the shorter version it will be incorrect in some edge cases, so it's really a perfectionist issue. I'm fine either way, I don't want this to become a distracting bikeshed

[fcurella]

enum for Django 1.8 and int for other versions

I can't find this in the diff. Can you point me to the right line?

[andreif]

Here you go https://github.com/fcurella/django-enumfield/pull/2/files#diff-174b02e9ae9348ecc51bb69323658307R48

Just to be clear, the issue is the result of my changes

[fcurella]

I'm not sure why this include is needed. Isn't this ocmbo already covered by python * env?

[andreif]

Yeah, annoying thing, but it's needed due to allow_failures

[fcurella]

oh i see

[andreif]

I've tried SubfieldBase and according to the docs it should have helped as far as I understand, but it did not. I am putting debugging on hold atm and will come back to it when I have more time.

[andreif]

We are discussing it internally and looking into dropping support for Django 1.6-1.7 to avoid inconsistency and therefore making major release. What do you think about it?

[fcurella]

Django 1.7 is still officially supported by the Django project, I would advise to continue supporting it until 1.9 is out of beta. I think Django 1.6 can be safely dropped as it's unsupported now.

[fcurella]

to_python needs to handle the following cases:

• value is None
• value is a string
• value is an enum

ref https://docs.djangoproject.com/en/1.8/howto/custom-model-fields/#converting-values-to-python-objects

[andreif]

enum.get does it

[fcurella]

It took some work to track it down, but I think I got IntEnum to work: https://travis-ci.org/5monkeys/django-enumfield/builds/86424033 5monkeys#28

[andreif]

Awesome!

[fcurella]

Looking good :)

I would add a Changelog (either its own file or a section in the readme) listing the breaking changes:

• django_enumfield.enum.Enum is now a subclass of the native IntEnum
• _transitions is now called __transitions__
• _labels is now called __labels__