Problem is caused by changes in the way the instance id is exchanged between the client and the server. Brixton.M2 modified the eureka registration model and introduced an explicit instanceId field whereas previous versions used a key in the metadataMap for this.
Concretely:
(1) Brixton.M1 client talking to Brixton.M2 server
InstanceId transferred as key in metadataMap. Server fails to interpret it and uses the hostname as instanceId.
(2) Brixton.M2 client talking to Brixton.M1 server
InstanceId transferred in the new instanceId field. Server expects it in the metadataMap but can't find anything. Defaults to hostname.
Interop can be achieved in case (2) by adding the instance id in both the metadataMap and the newly introduced field.
Comment From: spencergibb
I'm not sure that compatibility between milestones is worth it. I'm not sure what I would do anyway.
Comment From: brenuart
Maybe not between milestones indeed. But Angel and Brixton final releases will be incompatible. So either we find a way to bring back compatibility, either we should clearly state it in documentation or release note.
The problem is things will seem to work but not as expected. So people won't release it until too late. For information, Eureka will fallback to hostname if a proper instanceId is not found - this may lead to duplicates...
Comment From: spencergibb
@brenuart yes, I'll make sure it's documented and verify compatibility.
Comment From: spencergibb
Reopening for documentation.
Comment From: dsyer
See #978
Comment From: OlgaMaciaszek
The releases are no longer supported.