"Marking a message UDPDeprecated" means we've made extensions to the message that are only in the TCP/LLSD transport -- it can't be sent by UDP subsequently (this is OK because it will be possible to send almost any message via either UDP or TCP/LLSD). This also means that the message template no longer accurately describes the semantics of the message.

Marking as Deprecated an undeprecated message or a UDPDeprecated message. See example.

Marking a message Deprecated means that we don't send it anymore. We've either removed the functionality or replaced it with functionality that doesn't use the message system.

Adding a new message (why are you doing this, you fool?)

Arbitrary comment changes. More documentation is better, unless it's wrong, in which case it should be removed.

Checks to enforce The Policy

In order to enforce the compatibility rules, we have a well-known message template against which yours will be checked at certain times in the development cycle. Each check compares the master against your current message template. Every time you build or deploy, the production message template will be downloaded, and your changes compared against it.

The message template will be checked at the following points in time:

During a build (on all three platforms)

Just prior to deploy (via the farm command) to:

Development grids

Production grid

Your changes in relation to "Base"

When the check is run, it determines your message template's relationship to the production grid's template. This relationship will be one of:

Same

You have the same message template (modulo comments).

Older

The production template has compatible changes that are more advanced than your template (e.g. the production template has more blocks in some message, production has deprecated some messages, etc). This means that the production template advanced while you were hacking on your branch, or you branched off an old release.

Newer

Your template has compatible changes that are more advanced (e.g. you added some blocks)

Mixed

Both you and the production template have sections that are newer than each other, but in different sections of the template. This is akin to a merge conflict. (e.g. you've added a new message, and the production template deprecated a message).

Incompatible

You've made some changes that are incompatible with the production template. Bad developer, no biscuit. (e.g. changing the name of a variable, changing the size of a variable, deleting a block, pretty much anything)

Conditions for passing The Compatibility Test

Each point where the compatibility check is made has different conditions that must be satisfied to pass. Depending on what you're doing, the potential message template states listed above may be acceptable or unacceptable.

If you are deploying to production OR checking in to release:

ACCEPTABLE: Same, Newer

UNACCEPTABLE: Incompatible, Older, Mixed

If you're building locally OR deploying to a dev grid:

ACCEPTABLE: Same, Newer, Older, Mixed

UNACCEPTABLE: Incompatible

Examples of Compatible Changes

THIS IS THE ORIGINAL BLOCK TO WHICH OTHERS IN THIS SECTION ARE COMPARED.