x-ms-enum: we should revise enum deserialization to exclude a need of breaking change in case of a new value

This sounds like a good and immutable candidate for enum:

        "dayOfWeek": {
          "type": "string",
          "description": "Day of the week when a cache can be patched.",
          "enum": [
            "Monday",
            "Tuesday",
            "Wednesday",
            "Thursday",
            "Friday",
            "Saturday",
            "Sunday",
          ],
          "x-ms-enum": {
            "name": "DayOfWeek",
            "modelAsString": false
          }
        },

but owner team decided to introduce 2 more values: “Everyday” and “Weekend”. And it will be a breaking change in the generated SDK (at least in C# and Java) with unnecessary major version bump of the package. We need to have better handling of enum enhancements in our generated code to avoid this kind of “silly” version breaks in client libraries (Server API devs does not consider it as a breaking change and they will not change an API version for a new enum value).

For example we can introduce “Unknown” value as the first/default one in the generated enums and have a special handling/intermediate step in the deserialization component that will set Server returned values to Unknown if they are not in the current set of enum values.

[ro-joowan]

Folks from the Azure Data Lake team would also love to have this feature. Our current Swagger design was to set the enums with modelAsString: false. Therefore, moving to modelAsString: true now causes a couple of major issues: (1) The breaking change of moving enum type to string type for the customer and (2) The current modelAsString: true model creates a static class of the enum type, which prevents instantiation.

[brjohnstmsft]

Unknown is a lot less usable than getting a strongly-typed object that you can identify by looking at its underlying string value. That’s why we implemented ExtensibleEnum in the first place.