Is changing the number of an enum a breaking change?

Question

Consider the following code:

public enum SomeCode
{
     NIF = 0
    ,NIE = 1
    ,CIF = 2
    ,PAS = 3
    ,NIN = 4
    ,SSN = 5
    ,OTH = 5
    ,UKN = 6
}

Would changing OTH = 5 to OTH = 7 be a breaking change?

---

Edit: I never store the int value, only ever the text representation of the enum. It may be used in other DLLs, but will use the same storage.

Answer 1

It is a breaking change, as you are changing a public API.

Libraries/applications that were built with the old value will still hold the old value and use it. You will need to recompile them all.

From MSDN - enum (C# Reference):

Just as with any constant, all references to the individual values of an enum are converted to numeric literals at compile time. This can create potential versioning issues as described in Constants (C# Programming Guide).

Answer 2

It depends upon whether you have control over the complete code for your solution or whether you are exporting a library to be used by others.

• Maybe Not if all of the following are true
  • If it is just for your own use
  • You rebuild all
  • You only use the enumeration
  • You don't store the ordinal, cast to/from it, persist in a database.
• Yes if any of the following are true
  • If someone else is using your library and doesn't recompile, and doesn't use a version specific reference (assuming you're incrementing your build version) or a signed reference. The other code will have saved its own copy of the ordinal value, which doesn't now match.
  • You use explicit casts against the ordinal value
  • You serialize the data and want to use the old "save-files"

There are similar gotchas with publicly exposed consts.

In general, assume yes - it is a breaking change!

Answer 3

It will. Suppose you are storing some data as int from the enum, retrieving the data in the future will give wrong results. For the case, data stored for OTH before change won't come up as OTH as you are storing 5 for OTH currently and you will get 5 in the future and you need 7 for the same.

Answer 4

Firstly, both SSN and OTH =5, is it typo as otherwise it is compile time error for a switch statement using this enum? Now, changing OTH = 5 to OTH = 7, it would be breaking change if you are using enum as SomeCode someCode = (SomeCode)5.

Answer 5

It depends. It's a non-breaking change only if you can verify that noone depends on its value being 5 or the same as SSN or if you can refactor away such a dependency.

Answer 6

While it's true that it's not a breaking change if nobody depends on its value being 5, it's worth noting that anyone using it at all is depending on it being 5, even if that isn't explicit in their code.

If I write code against this assembly like:

if(myVal == SomeCode.OTH)
{
    //do something
}

Then internally that is comparing it to a value of 5. Even though the number 5 doesn't appear anywhere within my source code, so it will break if I deploy the new version of the assembly.

The saving grace is that I don't need to re-write to deal with this breaking change, just re-compile.