Even though I can honestly say that I have developed interfaces that could accommodate any change made to both sides without ever modifying the interface, most people don't design to that extreme. There will, more likely than not, come a time where you will have to change a message to accommodate a new feature or request, and so on. Now, we get into the issue of message versioning.

To enable support for versioned messages, we need to ensure the required components are configured. The simplest way to achieve this is as follows:

var bus = RabbitHutch.CreateBus( "host=localhost", services =>   services.EnableMessageVersioning() )

Once support for versioned messages is enabled, we must explicitly opt-in any messages we want to be treated as versioned. So as an example, let's say we have a message defined called MyMessage. As you can see in the following message, it is not versioned and all versions will be treated the same way as any other when it is published:

public class MyMessage
{
public string Text { get; set; }
}

The next message that you see will be versioned, and ultimately it will find its way to both the V2 and previous subscribers by using the ISupersede interface:

public class MyMessageV2 : MyMessage, ISupersede<MyMessage>
{
public int Number { get; set; }
}