@jleclanche I agree - this is causing me some headache right now. Would you accept this also in 1.5?

Probably not; I think this is a really backwards incompatible item. I could see it in 1.6 if there is one.

I tend to look at it as relaxing the requirement. Any old value would still be accepted but would now be a string. I'm not keen on the idea of going through all this work and still needing to maintain a my own branch for production.

It requires a data migration though which I'm not a fan of working into 1.5.

But you'd accept making it a UUIDField like APNS and WNS for 2.0?

Sure.

Actually, what do you mean exactly? UUIDs are 128bit, the hexints are 64.

I was leaning towards converting any non-UUID value into a UUID using UUID5. The benefit here is all platform device_ids are now uuids. It would be transparent when adding device_ids to the system as we could convert any non-UUID into a uuid. We can also apply the same logic when filtering. This would allow application developers to use alternative values to the expected device_ids in situations where they have a more reliable way to determine the device id than indicated by the vendor.

Why uuid5?

UUID5 is based on a SHA-1 hash of a namespace identifier, a UUID we can specify, and a string, the device_id. This basically lets us create hashes using uuids for sources that are not uuids.

Alternatively, consider switching device_id to just a CharField across the board and let application developers treat it however they deem necessary.

I'd rather switch to a uuidfield which is zero-padded on the leftmost 64-bit.

I'd be willing to try that but I wonder if it would validate.

Switching to a UUIDField that is zero-padded is pretty trivial. I'll get a PR ready.

>>> import uuid
>>> uuid.UUID(int=123)
UUID('00000000-0000-0000-0000-00000000007b')

@jleclanche It also appears that the HexadecimalField is unused. Safe to delete fields.py?