Version Number and Git Branch Changes


I’d like to announce some changes that will coincide with the next stable release.


We are changing to a semantic version system and will no longer use the 4 digit build numbers for stable releases.

The next release will be 0.69.0. The next release after that will be 0.70.0. Should 0.69.0 require a hotfix, it will be 0.69.1.

You will see these new version numbers across Interface & Sandbox wherever they are currently displayed (protocol mismatch, about menu, application title bar, update window, etc.)

Nightly builds will still use the 4 digit build numbers, but additionally have the abbreviated git SHA for the commit that they are built from.

For Developers: Git Branch

When 0.69.0 is released, the highfidelity/hifi repository will no longer have a stable branch.

Instead, we will be using release tags to identify the latest stable release.

Currently the repository has release tags for all releases, including master builds. When 0.69.0 is released the old master release tags will be removed and only one tag for the 0.69.0 stable release will be present.

When 0.69.0 is released, to retrieve the latest stable code in the repository you will need to checkout the latest release instead of checking out the stable branch. You may need to update any scripts that currently rely on checking out the stable branch to access the latest release.

It is unfortunate that the new method to identify the latest stable release in git is slightly more complicated. This change is required because keeping the stable branch with our updated release flow would require constant re-writing of the history of that branch.


Can we have an example of what the release tag will look like? I’m pretty sure most people operating their own servers would like to have some idea on what to expect before the new version comes out and all server operators are scrambling to update their stuff due to not having information in advance to something changed this critically.


I had hoped to capture the necessary information in the original post - I apologize if I did not go into enough depth.

The next stable version is likely to release early next week. Today we will be cleaning up the release tags on GitHub and I will add a tag for the current stable release, 68.1, in the new format. I hope that this will give some time to adjust scripts or commands in preparation for the release. I will post here when that tag is created.

Here are the commands that would fetch the latest releases and then check out the latest release tag:

git fetch
git checkout $(git rev-list --tags --max-count=1)  

Note that currently the latest release tag is latest master, but we expect to be changing that either today (Friday June 29th) or Monday July 1st.


If you would like to test retrieving the latest stable release with these changes , the latest and only release on our GitHub is the latest stable version v0.68.1.

Early next week a second release will be added for v0.69.0. Around that time the stable branch will be removed.

We have removed all historical master build releases and will no longer be publishing tags for master builds.


The next stable release (0.69.0) is likely to occur sometime around 9AM PDT tomorrow.

At that time the latest release tag will be v0.69.0 and the stable branch will be removed.


For those who still want the tag name and not the commit ID:

git fetch
export RELEASE_NUMBER=$(git describe --tags $(git rev-list --tags --max-count=1))
# returns v0.68.1 (for now)

Since I do keep a hold of older versions, this will allow you to have folders with the version number on it and not some cryptic hash. And the checkout system still works fine:

# preferred method
git checkout tags/$RELEASE_NUMBER
# or (sometimes works)
git checkout $RELEASE_NUMBER

EDIT: Actually, that just dawned to me: how are beta builds going to work? Say someone wanted to build the RC for 0.70.0? Would they just build off the branch for that, or will separate release tags be made for beta?



I think you’re asking about the latest version of each release candidate, before they become the latest stable release (we typically refer to our stable builds as beta, since that’s a label we still apply to the product as a whole).

When we cut off each release candidate, we create a branch v0.X.Y-rc. You can check out that branch to get the latest version of that release candidate. Note that until the release candidate is promoted to stable additional commits may be merged into the release candidate branch, so continuing to pull the latest for the branch is good practice.

For example, here’s the release candidate branch for 0.69.0 - Note that this branch is missing the prepended v but it will be present in the future.

If I have misunderstood what you meant by “beta builds” let me know and I will get you the information you are looking for.


Version 0.69.0 has been released -

The stable branch has been removed.