At the performance report I see the “Affected Version” is 1.0
Where can I set this version number?
(Unity 5.4 target platform: Windows / x64)
Hi Hyp-X,
The Affected Version number is grabbed from the Player Settings in Unity. To set that version, go to Edit–>Project Settings–>Player, then hit the tab with the icon of a phone to switch over to iOS settings. Underneath Identification you will see Version tucked between Bundle Identifier and Build.
Setting Version will change the version of your app the next time you build or run your project. I hope this answers your question and let us know if you have any other comments or concerns.
Thanks.
I didn’t want to download and install iOS support, just to set a variable, but I found I can set this manually in ProjectSettings.asset as “bundleVersion” or from script as PlayerSettings.bundleVersion
This code should help most people (BuildInfo.buildNumber needs to be substituted for something that you have in your build system)
using UnityEditor;
using UnityEditor.Callbacks;
public static class VersionHelper
{
[PostProcessScene(10)]
static void SetBuildVersion()
{
if (EditorApplication.isPlayingOrWillChangePlaymode)
PlayerSettings.bundleVersion = "Editor (" + System.Environment.MachineName +")";
else
PlayerSettings.bundleVersion = "Build " + BuildInfo.buildNumber + " (" + System.Environment.MachineName + ")";
}
}
Made a little editor window that lets you set the version number using the same PlayerSettings.bundleVersion
using UnityEngine;
using UnityEditor;
public class VersionHelper : EditorWindow
{
string versionNum;
string lastVersion;
bool changed;
[MenuItem("Window/Version Helper")]
public static void ShowWindow()
{
EditorWindow.GetWindow(typeof(VersionHelper));
}
void OnGUI()
{
if (!changed)
{
versionNum = PlayerSettings.bundleVersion;
lastVersion = versionNum;
}
EditorGUIUtility.labelWidth = 80;
versionNum = EditorGUILayout.TextField("Version", versionNum);
if(lastVersion != versionNum)
{
changed = true;
}
if (changed)
{
if (GUILayout.Button("Set Version"))
{
PlayerSettings.bundleVersion = versionNum;
changed = false;
}
}
}
}
Maybe you should change (or let the team in charge of the player settings know) that the version number should be accessible from other platforms too? Telling a standalone only dev to download and install support for a mobile platform to change the version number of your game sounds wrong.
This is still an issue, and I concur 100%! Or at least document how to change it via code, which is what we wanted to be able to do anyways!
Hi @Tuni and @Arthur-LVGameDev ! You’re right that this is still an issue and needs to be better. We’re hoping to add a universal version that can be used by the entire Editor without requiring any specific platform in the future.
Does Unity have a recommended practice for how to better control version reporting in Game Performance Tools now that we no longer call CrashReporting.Init() in Unity 5.5? Here’s a specific example where this is problematic:
- Our team starts working on version 1.5.0 of our game.
- We set the Application.version value to 1.5.0 in the Build Settings.
- We begin development, distributing multiple test builds to our network of testers over the course of a few weeks.
Previously we had been using an internal buildNumber property that we append to the Application.version value when initializing CrashReporting. We appended a suffix like this “1.5.0b1”, “1.5.0b2”, “1.5.0b3”, “1.5.0b4” so that we could get versioned error reports to appear in Game Performance Reporting that we could filter on. Since iOS doesn’t allow you to upload builds with a format like this, how do you recommend we move forward to get clear error reporting per version during testing? We don’t want to change our versioning format, but currently we have no way to get errors broken down per test build. We preferred the old way where the developer was in control of the version passed into the system.
Hi @TitanUnity ! I tried using a similar naming format (“1.5b1”) for one of my test projects and was able to build just fine to my iPad mini running on iOS 10.2.1. The crash reports from this build can be filtered by that version, as well. I’m not sure what format restrictions you’re seeing on your end. Can you point to anywhere online that mentions this or screenshots of errors that you’re seeing in Xcode when you try this format?
If for some reason you can’t using letters in your version format, perhaps you could try underscores? I tried that as well with iOS and didn’t have issues there either. Maybe give something like “1.5.0_1” a try. I hope that helps to answer your question.
That would rock!! It’s way more complicated than I thought it would be lol
Any updates on this feature?
+1 for me - I’m currently doing a custom script with auto version date - it’s less than desirable.
How is this not a feature, yet D:
do u know how to throw user to play store for update when new version release
@Ryanc_unity any update on this feature, again having to change settings in a different platform not ideal when auto retrieving version number.
I think you wanted @Ryan-Unity
You don’t need a script or to add any iOS support.
- Edit > Project Settings > Player.
- Under “Other Settings” there is a “Mac App Store Options” section.
- Change the field labeled “Version*”.
In 2019.2, the fields are labeled better.
- Edit > Project Settings > Player
- Android tab > Other Settings > Identification section
- Change the field “Bundle Version Code”
my hero and savior
For what it’s worth, we gave up on using the built-in “version” stuff for this & finally resorted to using a “TextAsset” that gets created during our build process.
How it works:
During the build process [at the very beginning], we instantiate a small “BuildVersionInfo” (derived from ScriptableObject) and then we serialize it to JSON and save it as a “.asset” file in the Resources dir. The game loads the TextAsset at startup and reads the version data from the text asset.
Initially we used some assembly trickery to identify build date, but after some time we ended up needing a bit more version data/meta-data (ie ‘branch’/built ‘intent’ and the SHA1 from source control).
Overall, our solution works just fine – and means we aren’t reliant on Unity functionality potentially changing in the future for our “public versioning” purposes. It did take a few hours to make sure it worked correctly with the “build sequencing” as far as assets/asset database goes, but it worked, and that’s all we wanted so we could get back to gameplay code.