Release.md

Proposal for release versioning

• We use a semantic versioning (e.g. 1.2.3-400)
• Major, minor or patch only get incremented on production releases, 1.2.3 -> 1.2.4 or 1.3.1 or 2.0.0.The build number can be omitted or hidden when displaying this release version to humans. Code always passes around full version string.
• We have a build version, that gets incremented on any packaged build, for testing (1.2.3-400) -> (1.2.3-401).
• Obviously follow conventions for when to increment major, minor or patch
• Staging releases are test releases so they increment build number

Upsides

• Cleaner releases. Want to avoid versions like 1.0.367.
• Have nice increments so people know how many versions they are behind. 1.0.1 -> 1.0.5 vs 1.0.367 -> 1.0.634
• Semantic versioning is a standard.
• Can auto package and deploy builds. People can subscribe to build increments.
• Difference between build vs patch increment is useful information.

Downsides

• Packaging needs to support reading build number
• Extra complexity

Sounds good.