Release Process

What do we need to do for a software release?

Update our internal project tracking systems
- Close the sprint
- Update and close issues
- Update our internal documentation e.g. wiki
Prepare additional materials for the release
- Release notes
- User documentation
- Update build scripts/configuration
- Build installers

You should version your software, so that every release has a release number and date associated with it.
The standard convention is a triple, separated by decimals, of the format: major.minor.build. For example, 1.2.3 would be major version 1, minor version 2, build 3.
- Major signifies a major product release. This is somewhat arbitrary, but typically is released infrequently and includes major features changes or additions. If you charge by release, you would typically charge for every new major version. You might release a new major version as frequently as once per year, or as infrequently as once very few years.
- Minor indicates a minor product release, typically a combination of new minor features, and bug or compatibility fixes. You might release a minor version a few times per year and users would not ordinarily expect to pay for these.
- Build number is internal build number within a minor release. This is intended to reflect bug fixes only; you typically iterate over builds internally and release the final successful version publically.