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.

EDIT: What about a process that QA themselves can run to remove the "RC" indicator? That might be an interesting way to handle it.

  • I am guessing you are not using visual studio? Jun 6, 2012 at 20:26
  • We are. QA is not.
    – Matthew
    Jun 6, 2012 at 20:45
  • I think the title of your question should more clearly reflect your actual question. Although I have exactly the same question as in your title, I can't really use this discussion, because it mainly talks about how to remove the watermark (or any other indication) from a build. Feb 23, 2017 at 8:27

3 Answers 3


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.

  • This will effectively require QA to "re-validate" a version... What happens if they fail it at that step? Then we still have an un-marked version "in the wild"... perhaps my concerns aren't valid scenarios but I'm thinking about this problem more philosophically than anything else.
    – Matthew
    May 31, 2012 at 22:13
  • It shouldn't be "in the wild" -- only the QA folks should have access to it. Your process will depend in part on the platform for which you're building: Is code signing involved? Can you include a build number with the app version? Anyway... if QA approves a release candidate but fails the "golden master" version, then either you screwed something up in the (hopefully trivial) process of creating the golden master, or QA changed the test process. Either one is a problem that you'll need to address.
    – Caleb
    Jun 4, 2012 at 17:26
  • So then QA would be in charge of signing the files?
    – Matthew
    Jun 6, 2012 at 17:21
  • 1
    @MatthewPK If the QA folks are willing and able to take on that responsibility, that could work. Some places have a Configuration Management group that's responsible for doing all final builds. I don't think that the details of the process are as important as simply having a well-defined, well-known process that includes some sanity checks to make sure that the QA-approved version is the version that gets shipped.
    – Caleb
    Jun 7, 2012 at 13:15

Let us look at this the object oriented way. A project just has a version --in the sense that a code change makes it is different from its previous version. Therefore, version must be a property of the project.

On the other hand, a project (in most cases) does not test itself or certify it. That decision is made by the testing/QA teams. And hence, while you/they can label the project "Alpha", "Beta", "RC", "Gold", "Platinum", "Retail" etc. this labelling is not a property of the build but rather of your perception of that build.

It is tempting to store this information in the project itself (perhaps even in the AssemblyInfo.cs) but as your question and Caleb's answer shows it requires re-building the project after each stage (to edit/remove the watermark).

So here is the solution --generate the watermark at run time by using another system (can be as simple as a web object queryable by your project, a simple file, database entry --you decide). The key is to keep this system outside the project scope and only have the testing authorities update the build "watermarks".

Here is how this system looks like (with the timeline):

  Version  |   Status |    Comment
    1.0    |   Alpha  |  First dev. build released
    1.0    |   Beta   |  Dev. team tests and decides to release it as beta without any code change/rebuild
    1.0.1  |   Beta   |  QA team identifies a bug, dev. fixes, rebuilds, updates the version, sends it for more testing.
    1.0.2  |   Beta   |  QA team identifies a bug, dev. fixes, rebuilds, updates the version, sends it for more testing.
    1.1    |   Beta   |  QA team identifies a bug, dev. fixes, rebuilds, updates the version, sends it for more testing.
    1.1    |   RC     |  QA team promotes it to RC build. You send the exact same build for user testing/preview.
    1.1    |   Retail |  Users do not report bugs, QA team also does not. You decide this build (without any change) can be shipped to retail.

An added advantage of this system is that you control the build tag and can easily create a newer tag (e.g., expired, recalled) and push it out without application reinstalls or rollouts. As a fail safe, the watermark should show a default value or last queried value in case it cannot establish a connection to the system.

Edit: If you are not fan of external systems, then just keep a simple file within the project itself but not embedded into the main assembly/jar/etc. This file can track the build watermark. The key is to not embed the watermark into a unit that has to be compiled in order to be changed.


You should explore Visual Studio's Configuration Manager. It can do what you want it to do. We implemented each configuration with a different Installer Project so that for each build all that was needed was to run compile on the installer project that the desire was to build. We incorperated Dev/Test/prod watermarking scheme into that.

  • But how does the installer project control watermarking in the application?
    – Matthew
    Jun 7, 2012 at 20:27
  • You can do that in your configuration manager. The installer projects set the configuration to use. This allows the devs to never have to change from debug mode. It requires a little maintence on the config files occasionally. But once you figure it out its mostly copy and paste into new projects. Jun 8, 2012 at 12:49
  • Can you provide me with a little more documentation on this? I'm having a hard time finding any good links. Is this something we would do in the wix?
    – Matthew
    Jun 8, 2012 at 14:16
  • Matthew We had a small image 20x40p as I recall that said DEV, TEST, or {ProductName} That image path was a field in the config. The config used was based on the installer package that was built. It really was not that hard. Jun 8, 2012 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.