We're trying to implement a strategy for how we transition our builds from RC to released retail code.
When we label a build as a release candidate, we send it to QA for regression. If they approve it, that RC then becomes our released retail code.
I liked the idea of "obvious" labeling of versions so that a user knows whether they have a beta or an RC or retail code… where you would have some obvious watermark in non-retail code (think Windows 7 where the RC or non-genuine builds watermark in the bottom right).
… but it seemed strange to us to manipulate the project (to remove the watermark) once it passed regression. If QA certified version a.b.c.d then our retail code should be that same version, not a.b.c.d+1
what strategies have you employed to clearly label non-release software versions without incrementing your build to disable the watermarks in your retail code? One idea I've considered is writing your build to look for a signed file in the installer archive… non-release code wouldn't include this file and so the app would know to display a watermark.
But even this seems like QA is then working with non-release code.
Ideas?
EDIT: What about a process that QA themselves can run to remove the "RC" indicator? That might be an interesting way to handle it.
Best Answer
Follow your instinct. It'd be nice if you could make the release candidate look one way before release and another way afterward, but you're right: it's important that the released version be exactly what QA approved. In my experience, the usual MO is:
Produce test (alpha, beta) versions that are clearly marked. Send them to QA for testing.
As you get closer to release, produce release candidate versions that are again clearly marked. Send them to QA for testing.
Once a release candidate gets the seal of approval, produce a final "golden master" build that is exactly what you intend to ship. No "golden master" or "release candidate" markings. Send that to QA one more time.
When QA approves the golden master, ship it. Or better, have them ship it so that there's no question that the version they approved is the shipping version.
It's still a good idea to come up with some technical means for turning the "test" markings on and off. That'll help you minimize the steps that you have to perform between approval of the final candidate and the shipping version. My point here is just that you should have QA review the product after you've performed those steps, whatever they are.