When should I update the version number? Should I change the version number every time I make a code change? There are several standard practices for versioning, but every versioning scheme should answer when and how the version number changes. Version numbers are simply number sequences, or even just a single number, that uniquely identifies a build.

Consistent - We use the same workflow throughout production and after launch.īefore I go into how or why we do it this way, I want to dive into the basics of versioning a bit so that everyone can follow along.

One Step, One Truth - there is only one place to set the version: the git repository.

Requires No Commits - Ticking up the version doesn’t require committing code changes or settings files.

Automated - It’s as automatic as you can while keeping versioning meaningful.

Our versioning workflow has a few big selling points: The only manual work is to tag the repository for major and minor releases.

Sparklite uses Semantic Versioning (v1.0.0), enforced using git and an automated build system. This blog post as a Twitter thread Sparklite Versioning in a Nutshell (or Why You Should Keep Reading) If you’d prefer a more concise description of our method, here’s the same content as a Twitter thread:

This post outlines the thought behind our versioning method, and explains how you can apply it to your Unity project if it sounds right for you. When we do a major build, we tag our code repository and package the build. It will automatically be given a new version number. With our versioning workflow, when we make a simple change in Sparklite, we just package the build. So early on we took a good amount of time to figure out a system that would work painlessly throughout production. Tagging your builds with an identifier (which is all that a version number is) is also useful for bug reports, so that QA can tag each bug with the version it appeared in, reducing the waste of reproducing bugs that are already fixed.īut manually updating the version is a pain, it’s prone to error, and it goes against my core being. This might be when you start taking it to trade shows, giving out demos, or at the very latest by the time you ship because it’s required by platforms.

At a certain point in a project it’s a good idea to start keeping track of your builds and the code used to generate them.

Unity cloud build project version