In SCM We Trust

Consider the following SCM tool-agnostic sequence of events:

1. codefreeze.


2. fix, fix. label RC1 --> build. package. deploy. test.


3. fix, fix. label RC2 --> build. package. deploy. test.


4. fix, fix. label RC3 --> build. package. deploy. test. Verified!

Now what? Do you....

[A] Declare RC3 the official release label and "copy" the verified package to production? The actual verified code is in production but how does someone really know from SCM that RC3 is in production? maybe RC3 was rolled back and RC2 is in production. How does someone know that RC4 isn't being worked on?

[B] Subsequently create a new release label with an official "event describing" name like "Release_X.Y" then rebuild, repackage and deploy to production? The new label accurately describes the official release and demarcates the end of release candidates but the rebuild and repackage were not verified. Do you trust your build system? (topic for a separate post)

[C] Deploy the verified code but subsequently create a new "event describing" label like "Release_X.Y" and trust that the configuration for the new label is identical to that of deployed RC3 configuration? Developers may fix bugs using the new release label but technically it wasn't used to generate the actual production code.

I advise doing [C]. Though, it helps to have a transaction-based SCM system (like AccuRev) where the label operation simply marks the transaction # rather than each-and-every file in the configuration - afterall, tainted files are untested files. This way, as long as two labels refer to the same transaction, they will refer to the same configuration.