How to choose my app version

I built an app.
How can I choose it version.
What can be its major, minor and bug version. It is the latest app.

If tested and stable, first public release, probably 1.0.0.n

here n is 0

Turn ON “Auto increment Version” and n will get +1 on every build.

Look on the shared Build settings in your project. It’s at the bottom of the project inspector, as Rick said 1.0.0 is the standard first release version number. Numbers below that tend to be for test releases.

If you release a new version that fixes a few bugs increment the Bug Version number.

If you add a few features increment the Minor Version and reset the Bug Version to 0.

If you make a wonderful new version with significant changes increment the Major version and reset both the Minor version and Bug version to 0.

4 Likes

I go a bit different
Major - Current Year (a xojoscript autoupdates this entry)
Minor - Current Month (a xojoscript autoupdates this entry)
Bug - Current Day (a xojoscript autoupdates this entry)
Non Release Version - Auto increments itself

4 Likes

If I understand his question correctly, I may have the same question actually. Not sure which release of Xojo he’s using, but I’m on “latest” also (Xojo2021r3.1) and how the heck does one define which version the built app will have? Under RealBasic, we used to click on “App” in the project list and the property panel would have a ton of stuff we could configure such as MajorVersion, MinorVersion, BugVersion. Where are those now in Xojo? When I click on App, I only get Default Window, Menu Bar and Icon. Nothing else. It’s missing like 20 more fields.

@Ben_D

Under Build Setting click on Shared and you will see the build info

This mess with the purpose of such fields. If your software demands a continuous delivery, ok, your users will get used to it, but if it has gaps in time, I don’t like it. Users do expect that when the Major number changes, new features and major changes are introduced. When minor changes, few features and corrections, when bug changes, some problems were found and corrected, and the build (non-release) is more for internal tracking. So people may have the wrong impression that the first release of the year of your app must have major changes or features, even when you intend just release a bug fix edition. This automation laziness may affect the user perception of the release cycles, quality, care, and stability of some apps. I do prefer crafting those numbers according with the reality and the designed purpose.

1 Like

Where the heck is “Build Setting” tough, that’s the question!
1

This may help:

2 Likes

OH MY GOD! WOW. I would never have found that by myself it seems! Wow. Thanks. Hope it helps OP too.

1 Like

Well it’s not laziness. It is a web app with 4-5 releases per week, and sometimes even 2 in the same day. So yeah, automation is needed for this type of release cycle.

It’s what Xojo does, and no one thinks that.

1 Like

@Greg_O Well Xojo does year in major version, but I don’t think I’ve ever seen month and day used for minor / bug versions before.

It would be great if you could provide a XojoScript code example. :slight_smile:

The script has to be placed before Build, not after.

Var result As String
result = DoShellCommand("date /t")  ' I compile on windows os and it gives me 05.04.2022

PropertyValue("App.MajorVersion") = result.NthField(".", 3) ' year
PropertyValue("App.MinorVersion") = result.NthField(".", 2) ' month
PropertyValue("App.BugVersion") = result.NthField(".", 1) ' day

Now, depending where in the world you are located, the date might be formatted different from mine. Experiment with the nthfields above to get what you need.

3 Likes

Thank you :slight_smile:

You should post this in the Code Sharing category.

Good point. Done that. Thanks for the suggestion. I forgot that that category exists :slight_smile:
They should make it more prominently.

1 Like