Move Away from Enum Binding in .NET Package

[lukecusolito]

In recent months, our integration with Xero’s new subscription plans has unexpectedly broken twice due to the .NET package parsing API response properties as enum values. Specifically, when the API call (e.g., GetOrganisations) returns a 200 status, the result is empty because the organisation is returned with a new enum value that the older package version cannot parse. This issue arises whenever Xero’s API introduces a new enum value, causing all clients using prior versions of the package to break.

To prevent such breaking changes, I would like to request that you consider moving away from binding to enums. Instead, represent these values as strings. This approach would provide more stability and prevent integration issues when new enum values are introduced.

Additionally, I’ve noticed in recent commits that numerical enum values have been altered. Changing these values is problematic as it breaks integrations where the enum values are stored. I strongly recommend avoiding modifications to numerical enum values to maintain backward compatibility. I have attached this commit below.

5c1274b

[github-actions]

PETOSS-544

[github-actions]

Thanks for raising an issue, a ticket has been created to track your request