Auto-increment version project

version_auto_inc
Input in the Version field is processed and only allows input by masks:

  • 0.0
  • 0.0.0
  • 0.0.0.0
    In any case, the value is ignored and the previous value remains.

If the (Auto-increment Build Number) checkbox is checked and when performing the operation, Build and Publish will be automatically incremented by one after the version value.
Examples:

  • it was 1.0 - it is 1.1,
  • it was 1.9 - it is 1.10,
  • it was 1.0.1 - it is 1.0.2,
  • it was 0.1.1.2 - it is 0.1.1.3.
1 Like

Maybe it’s even more helpful to add a seperate property for the build number that’s automatically incremented and included in the Main.hx (and can be reset)?

  • This field sets the value in the arm_project_version field. This property is included in Main.hx.
    write_data.py:

    with open('Sources/Main.hx', 'w', encoding="utf-8") as f:
         f.write(
    """// Auto-generated
    package ;
    class Main {
     public static inline var projectName = '""" + arm.utils.safestr(wrd.arm_project_name) + """';
     public static inline var projectVersion = '""" + arm.utils.safestr(wrd.arm_project_version) + """';
     public static inline var projectPackage = '""" + arm.utils.safestr(wrd.arm_project_package) + """';""")
    
  • The user can specify any value and it will be automatically added. If you want to reset, specify a different value.

Does this mean or what else?

What I wanted to say is that there is a semantic difference between a build number and a version number. Different version numbers usually describe differences in features of a program whereas build numbers just describe one particular build (this can be used to describe exactly where a bug occured for example, even if it’s not code related but caused by some problems in the build pipeline).

So separating those numbers into two different properties might be a good idea, but I don’t know how the details should look like (is it reset for each version for example?).

Edit: actually, I don’t know if it’s really useful to separate the build number from the version number… It was just an idea. The Auto-increment flag seems pretty self-explanatory.

The version number consists of major.minor[.maintenance[.build]] or major.minor[.build[.revision]]. Builds are usually sequentially numbered.
In any case, only the developer knows what has changed and how it affects not the version, automatically we can only read Build. As a result, we will have either 2 fields that will form the application version number or one (as it is now).
Considering how it is done in other IDEs, the options are as follows:
Visual Studio:

Code Block:
autoversion_editor

X-Code:

What is meant? Do you want to fix something in the interface?

1 Like

No, it looks good as it is, that’s what I meant. It’s easy to understand (=it explains itself without having to look it up. I was afraid first that people are confused why the version number gets higher, but its pretty clear why and this is deactivated by default I think?)

Great work as always :slight_smile:

3 Likes

Thank you so much :slight_smile:

Didn’t specify defaults:

  • Version - 1.0.0
  • Auto-increment Build Number - enabled.
4 Likes

Added input processing for adjacent fields:
check_field

  • Name - the field must not be empty. If the user tries to set an empty value, then this field specifies the name of the blend file (this is how it is implemented during assembly). The default is the name of the blend file.
  • Package - the field must not be empty, it must not consist only of numbers and start with a number. The . symbol is replaced with _. The default is arm.
  • Bundle - the field must be filled in according to the mask [string].[string]. Each part must not be empty, contain numbers, or start with a number. The default is org.armory3d. Previously, this field was blank, in which case the current default was used.

For all fields, special characters ([] / \ ;,> <& *:% = + @! # ^ () |? ^) Are also replaced with _.

2 Likes