It standard feature for IDE and build process. If feature enabled every time when you build/bundle project last minor version number auto incremented on 1
I made an issue
1 Like
Hmm, I’m a bit sceptical. I assume you’re referring to project.version in game.project right? You mention both build and bundle, but I assume you mean only bundle?
Also, I guess it depends on how you decide to use the version number. Does a change of version number indicate an actual change of the code or the features of the app? Or does it as you suggest simply indicate that the developer has decided to make yet another bundle? Personally I prefer if the version number actually has some meaning and convey information about if and how much the project changes from one version to the next and not have it act simply as a build number.
What if you decide to make a new release of your multi-platform game and bundle for multiple platforms? In that case the different builds would have different version numbers unless you remember to disable the version increment after the first bundle.
I would argue that this kind of feature makes more sense to put in an external build script that you use when you release a new version (using bob.jar to build). Let the build script have an option to increment version and possibly also inject the Git commit as a custom key in game.project and then bundle for all of your target platforms.
3 Likes
Thank you.
Something which might help would be to be able to specify a script in the project folder to run before building / bundling.
2 Likes
I think I not full correct write.
I often make test builds/bundles(every day) and I need make different build numbers for every build(our internal rules), but I don’t want think about it every time. Usually in IDE present major, minor and build versions. Autoincrement work only on build version(checkbox present for configurate). I think it not special needed for bundle process(used last buld number), but for build it very important.
Using major, minor, build number is one of many different versioning schemes. Semantic versioning is another scheme where the last number isn’t a build version but a patch version. There’s a big topic on software versioning on Wikipedia where what you suggest with the third number indicating build number is but one of many different approaches to software versioning. Creating a solution that caters to just one out of so many options is not very good in my opinion.
With that being said, now that an issue has been created, I defer the final decision to the editor team.
1 Like
Hi @tarnumius!
Thanks for your feature request. We don’t want to assign any particular meaning to the version field so we’ve closed the issue. As explained in the issue we believe this type of problem will be solved later on by editor extensions or the ability to run scripts from within the editor. This is not currently a prioritised feature though
I hope you find some workaround meanwhile!
1 Like
Thank you. Before and after build scripts good idea too.
BTW, bob the builder on windows can not delete some dlls from tmp (texc_shared.dll) directory and die. Can you fixed it? Then I can create cmd file and it resolve my problem.
No I try few times. Every time delete this directory by hand. Files placed in bob tmp directory. Before bob die directory was locked, but after bob die - I can delete directory.
1 Like
Adding my voice, I have to agree that I think it makes more sense to do this in a build script. You could then at the same time you are bumping the version add a tag in git, build all platforms at the same time, save the builds in a backup folder, run any verification scripts you may have and so on.
That said, it would be very cool if you could hook this kind of things up with the editor. Further more it would be very beneficial if there was support triggering thing on Close, Open, Pre-build, Post-build as well as adding custom scripts to menys in the editor. Being able to extend the editor in a similar way you do with for example Autodesks Maya is a dream of mine. There is a ticket on the internal tracker Def 2859, I copied it to github. One can always dream.
2 Likes
I filed an issue for this, DEF-2866. I’m not sure if we will prioritise this with Editor 2 around the corner. But it’s probably a small bug which could increase the likelihood of us taking a look at it, no promises though. 
2 Likes
Thank you. I only make report And wait fix of course.
1 Like