Gltf-blender-io: Include exporter version in 'generator' string.

[donmccurdy]

Will likely be helpful down the road if assets include the version of the exporter used. I.e. replace Khronos Blender glTF 2.0 exporter with Khronos Blender glTF 2.0 exporter (<version>), where <version> is either a commit hash or semver version.

[donmccurdy]

With the exporter now in Blender Beta, probably we should change the generator string to just, Blender <version>.

[donmccurdy]

Moved to the new repo as I think this enhancement still applies.

[emackey]

Since we ship with Blender now, it might be enough to just grab the Blender version string (bpy.app.version_string) and append that to the generator.

[julienduroure]

We also have an addon version that is written in bl_info (currently 0.0.1), and displayed in addon tab of user preferences.

[donmccurdy]

Looks like most of the exporters show both a Blender version and an exporter version in their docs: https://docs.blender.org/manual/en/dev/addons/io_stl.html. We could include both in the generator string, I suppose..

[emackey]

I'm OK with writing both, if that's not too crowded. Usually the only people looking at it are the people trying to debug something, so, more info is better.

Separately, we should establish some process or schedule for bumping the version number. It can't stay at 0.0.1 forever.

[donmccurdy]

I think I'd vote to bump the version when we submit an update to the Blender repo. Using https://semver.org/ seems as good as anything, unless the Blender project has another system? We can add a version.sh script to automate this if needed.

[emackey]

@pjoe and I were talking about this on the KhronosDev #gltf channel.

There's a file convert_to_strict_2.80.py that could potentially be used to write a git SHA1 value into a version string someplace.

But, Blender addons do use SemVer, not SHA1s, and we've had the 0.0.1 version for far too long. I think it's well past time to at least declare 1.0.0 on what we have now. We could then be more rigorous about incrementing the number with each major PR, or with each copy to Blender.

Also, it looks like the generator string was never updated to include the version number. That would be a great thing to start doing right away, especially as we are seeing more sample output being submitted with bug reports.

[pjoe]

At least this would be a huge improvement in ability to track a bug appearing in a given blender release back to git history here :) Especially with the current way Blender 2.80 works where most people use some nightly build, where it is quiet complicated to back trace where that belongs to here.