Deserialize speaker as an int not a string

[DamienDeepgram]

Speaker is an int not a string

speaker: 0

[lukeocodes]

@CopperBeardy @ThindalTV chaps can you run your eyes over this. Can you tell me if this is a breaking change for existing implementations?

[ThindalTV]

Unfortunately, yes.
It is a good catch and something that should definitively be done, but it will break user implementations that use the speaker value and treat it as a string.

[DamienDeepgram]

This was added last week (#138) for a specific customer and they reported that it should be an int not a string.

I think it is safe to update given how little time it has been present as prior to the above PR the value was actually missing

[lukeocodes]

This was added last week (#138) for a specific customer and they reported that it should be an int not a string.

I think it is safe to update given how little time it has been present as prior to the above PR the value was actually missing

I appreciate the sentiment, but semver is concrete and breaking changes are major version bumps

[lukeocodes]

Digging further into this. Given the userland workaround to this is int result = Int32.Parse(input); I am going to suggest we include this change in the rearchitecture planned for this SDK in Q4. A string -> int data type change is a breaking change, and requires a major version bump to introduce.

At this point, with a major version in the near future, we'll close this ticket in favour of including it then.

Thanks! (see Discord for the discussion).

[jpvajda]

@DamienDeepgram - Just closing the loop in this, We can plan to implement this change in our next Major release of the SDK which is something we are beginning to plan now with our community members. I'm going to open an issue for this to ensure it's accounted for. see #145