Update: You can specify this by modifying .build. I’ve written about this here.
When you upload your APK to Google Play, and then later you need to upload a newer version, you may run into (I did) a mysterious error that app version must be greater than X for some arbitrary version X that you previously uploaded for that app.
It turns out that the android:versionCode which gets put into the generated AndroidManifest.xml takes it’s value from the .build file. I have some beef with this:
It’s not documented or described anywhere.
It’s arbitrary. If you clean or delete export and rebuild, it resets to 1
Today, the project configuration (Project.xml) allows you to specify the following attributes on the app tag:
title
company
package
version (eg. 1.0)
Could you please add a version code attribute?
I don’t know if there’s a way to generate a consistent version code that doesn’t get cleaned/reset.
I know about overriding the manifest. I consider it a fragile (tightly-coupled) work-around, because new versions of OpenFL could always end up generating different (better) manifest files, and I would be stuck with a snapshot of an older manifest.
Besides, why would I want to override and keep a copy of the whole file, when I really just need one property changed? I can already change everything else I need for publishing to Google Play, by changing the project XML file.
I believe many platforms have the concept of a build ID, which a universal integer value, which is used as the “true” version value, rather than the string “version” value which the user will see.
If you have recommendations for improving how this is handled, I’m open to it. It’s a tricky thing to decide how to balance between something that will be seen (and committed to version control) or not.
It should not be removed on a -clean build, but it would be removed if you delete your output directory. Perhaps it could be saved alongside the project file, but I think it was moved to make it less visible.
You can do <app build="" /> to force a build number, but this is not currently recommended
I think I put the .build in the same directory as the project.xml originally, or perhaps used the same name, but with the .build value (such as project.build or project.xml.build), but I got a lot of feedback (if I recall properly) of “What is this file?” and “How do I get rid of it?” and it was sometimes funky when using an editor such as FlashDevelop, that shows the file disappearing or appearing.
Then again, perhaps that was all before I treated it as a hidden file. I don’t think it’s flagged as hidden on Windows, but it could be. Another possible idea (under the export directory would be my first thought) is a more generic “properties” system that could save the build file data, as well as other build properties that might make sense to dynamically perpetuate between builds.
My suggestion is to make it optional: if the developer moves the .build file to the project root, keep it there. But if it isn’t there, default to the export folder.
This will allow people who care to keep it around, while everyone else continues as normal.
I hope this thread, and my blog post on this topic, will serve as sufficient documentation/warning to future developers.
My recommendation to OpenFL consumers @singmajesty is to leave the .build as-is (don’t check it into source control), but manually change the number to something sufficiently higher if you run into a situation where you can’t publish a newer version of your app.
Most of the dev time I don’t need it to increment. And when I realy need it to be larger I also need it to refer special git commit. That’s why I made simple bash script that reads current rev count from git repo and updated project xml build-number with it through sed -i
You can also do openfl test linux --meta-build-number=123 or what-have-you. This can be done more easily through a script, I think, than accessing the actual XML (and doesn’t trigger a change to be committed in GIT)
