Services/Sync/Server/ReleaseTagging

Normal builds

We should be targetting weekly builds for most normal code development. Normal development is for code that can be deployed non-destructively; there are no API changes, and no downtime is required for databases or the webheads.

Normal builds will be launched weekly on Wednesday.

To make this happen, the build should be ready to go by close of business on the preceding Monday. That build will be tagged with the current version and the Wednesday date (YYMMDD): i.e 1.3.100721. This will give QA Tuesday to test it (and part of Wednesday if needed).

If QA finds problems with the build, the revised version should be tagged with the same version number, plus a build id: e.g. 1.3.100721b2

Disruptive builds

Disruptive changes, where actual API calls are revised, or databases need to be brought down for changes, should be handled as special pushes (with an accompanying new version number) and are more likely to be deployed during a lower-traffic period.

They'll be tagged with just a version number: e.g. 1.4

Emergency builds

Occasionally, an error will be discovered on the live website for which the magnitude of the error exceeds the danger of a direct fix. This may be a data-affecting bug, or a security issue. These pushes go out without a signoff from QA. The tag for these pushes adds an emergency push number to the end of the current build id: 1.3.100721e1