## Changes that don't bootstrap

Sometimes changes need to be made to the Mercury system that mean previous versions of the compiler will no longer successfully compile the new version. Such changes must be split into two parts, where the first part adds to the compiler the capability needed by the second part.

Beside the new capability, which may be a new feature or a fix for an old bug, the first part should include a new user-visible name for the compiler option named compiler_sufficiently_recent. This name should include both a brief description of the change and the date on which the change is committed. The option name --simplest-msg-2019-09-22 is an example.

When the first part is committed, you should send an email asking all members of the Mercury team to install the updated compiler version on the computers they use, if this hasn't been done earlier (such as when the diff was sent for review). Then you should wait until

- a new rotd is publicly available for download which has the first part, or
- everyone on the team has reported installing a new compiler, or
- both.

The second change should then include an update of the test in configure.ac for whether the compiler is sufficiently recent. Specifically, you should add the new name of the compiler_sufficiently_recent option added by the first part to the option list with which that test invokes the Mercury compiler. Since the presence of each such name in the compiler implies the presence of all earlier names of that option as well, you should delete those earlier synonyms from the option list at the same time.