Build Number Guidelines

Context

On a complex software development project with a finite deadline and where multiple builds need to be delivered with clarity and certainty, it is advisable to map out the build number and build step requirements and guidelines. The primary reasons are as follows for all stakeholders:

• There is clarity on what to expect at each stage of delivery throughout the project.
• Supplied builds are more easily referenced within those expectations.
• Build numbers provided during feedback make testing and validating issues significantly easier.

Having a solid outline of what is required for each phase to be complete also aids overall communication. For example, in order to deliver a Beta release, all UI and al content must be implemented. In order to do that, all context must have already been supplied. Without all the content, a complete Beta can not be delivered thereby holding up the rest of the process. Having these stages clearly mapped out will provide clarity on when certain elements need to be supplied by external stakeholders.

General Build Expectations

These guidelines will vary slightly based on the following:

• The complexity of the project
• The expectations of the client and other stakeholders
• Build delivery mechanism
• Target delivery platforms

Mot all of these will be required for every project, and will depend largely on the information available up front as well as stakeholder expectations. Where there is an expectation for constant feedback, implementing all of the below stages might prove useful so that the overall understanding of what is to be expected is at all phases extremely clear.

• Prototype builds will contain basic functionality and user flow, and are useful to assess that the intention of the app has been correctly understood. They will not be pretty.

• Pre-Alpha builds will NOT be feature complete.

• Alpha builds cover all functionality (all UI elements) and one complete content slice, including at least English and basic animation.

• Pre-Beta builds will be feature complete but NOT be content complete.

• Beta builds will be feature complete AND be content complete, including additional language support and refined animation.

• Release builds will be completely complete, with no additional functionality required. Focus is on minor content updates and bug fixes.

• Install builds will be set up specifically for delivery to run on the target hardware.

Build Number Guidelines

These are all optional and will depend entirely on the use case for any particular project. Establishing these up front and sticking to them provides not only clarity, but also momentum to the team involved. Getting to the next phase by being able to tick over the minor number is a good feeling of accomplishment and helps to maintain momentum on a project.