- for now all versions start with v6.0
- CICD builds use the monolithic build number as patch level, e.g. v6.0.12345
- local builds use the following algorithm
- find the newest commit with a CICD build number that is included in the
working tree
- count the number of commits in the working tree since that commit
- if there are no commits since the last CICD build, the local build version
will be v6.0.12345-local
- if there are N commits since the last CICD build, it will be
v6.0.12345-N-local
- test builds in the CICD that don't create artifacts simply use a dummy release
in order to not incorrectly increment the build number and also not to waste
time and resources by manually checking out the nightly-build repo for each of
these builds.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
3.1.0 was never released, but this is a quick hack to work around a versioning
issue in the iOS app store. Not ideal, but at least it works.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Once again I have managed to get out of sync in numbering between iOS
and Android. I'll make new releases with the correct version number on
both platforms today.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Quite a few little changes lately that all deserve a new nobile app
release, and each release requires an updated version number.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is needed to be able to push new betas into the AppStores.
I keep forgetting to do that after I do a mobile release.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In order to be able to roll out new betas, we need to first increment the
version number. Given the magnitude of the changes, incrementing the minor
version (not that we have ever been really consistent with how we do the
numbering in the first place).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The mobile changes are far and few, but the next version will be the
first to support arm64, so a new minor number seems appropriate.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Apple app store rules prevent even testing a binary with the same version as one
that has been submitted for release.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Apple typically forces a much more detailed review if the version number
changes. Let's get this taken care of now as we prepare for release.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
