Special Versioning Cases

We use Semantic Versioning for our projects. This wiki page documents some additional conventions that we follow where there are complicating issues.

We will use the Semantic Versioning recommendations for alpha or maintenance releases, but that's not what's covered here. The conventions expressed in this document are for situations not covered in that guide.

Forks

When we have a project that we need to fork, where we want to make changes on the fork, but have our version numbers follow along with the origin's version numbers, we will use this convention:

X.Y.Z<project>x.y.z

Example, where the "platform" project is forked off into a "platform-cqa" repository to maintain an alternate feature set that we don't want to deploy with the main application:

3.1.0cqa1.0.0

In that case, if we make more changes based on that release, we might increment our version to 3.1.0cqa1.1.0. If there's a new release of "platform" as 3.1.1, then our next version would be 3.1.1cqa1.0.0, and so on.

Sort-order examples:

• 3.1.0-a1 < 3.1.0
• but 3.1.0 < 3.1.0~cqa1.0.0
• and 3.1.0cqa1.0.0 < 3.1.0cqa1.0.1

See the SemVer sort order section.