Have you been burned by versioning enums

  • Article

Kit George is working on a guideline
around versioning wrt Enums and he needs your feedback. "urn:schemas-microsoft-com:office:office" />

It’s a know issue that adding values
to enums is bad (from a breaking change perspective), WHEN someone is
exhaustively switching over that enum. For example:

I have an enum, with three elements
in it, and I have some API, which I have written to return a
Color:

public enum
Color { Red , Green, Blue };

public
class Service
{

public static
Color
GetColor() {

     
// returns a valid Color

}

}

 

Someone consumes this enum by
writing this (broken) code:

           
Color c = Service.GetColor();

     
switch (c) {

           
case Color.Green :

           
Console.WriteLine(“taking
some action based on Green”);

           
break;

           
case Color.Blue :

           
Console.WriteLine(“taking
some action based on Blue”);

           
break;

           
default : // Just
assume Red is the only other value

           
Console.WriteLine(“taking
some action based on Red”);

           
break;

     
}

 

The issue is: what happens when I
want to add more colors to my enum? For example, I want to change Color, so that
now, it has this definition:

public
enum Color {
Red , Green,
Blue, Yellow,
Purple };

 

Questions

  • Have you, or your team ever hit
    this problem with a managed API being updated in this way (an element added to
    an enum), and affecting your code?
  • Same question, but for an
    unmanaged API?
  • If you weren’t aware of this issue
    previously, do you think it might affect your code in the future?
  • What if we simply allow this kind
    of change: do you think it’s that bad?