Versioning idea for Blender

[timsutton]

Since Blender seems to have a pattern of 1.23, 1.23a, 1.23b, 1.23c, 1.24, etc. in its official release versioning and this poses a couple issues with these recipes, I've been doing this for a couple recent Munki imports:

1. Convert the alpha character to a .0, .1, etc. for the pkginfo version. So for example, 2.78 becomes 2.78.0, 2.78a is 2.78.1, etc. This way the versions sort logically.
2. For the two installs applications, use their CFBundleVersion for the version_comparison_key.

Their CFBundleVersions are not standard, but LooseVersion does seem to sort them as they should be, thanks to the use of the YYYY-MM-DD in the string and them not actually using alpha characters along with the version:

In [1]: from distutils.version import LooseVersion as LV

# comparing 2.78 to 2.78c, which doesn't put the alpha character in CFBundleVersion (or anywhere it seems)
In [2]: LV('2.78 2016-09-26, Blender Foundation') < LV('2.78 2017-02-27, Blender Foundation')
Out[2]: True

# theoretical later release with a newer version
In [3]: LV('2.78 2017-02-26, Blender Foundation') < LV('2.79 2017-05-27, Blender Foundation')
Out[3]: True

This is the strategy I've been using to update 2.78 to 2.78c and it's worked ok. I had missed 2.78a and 2.78b because AutoPkg sees the 2.78 version and skips the import unless you force it.

I haven't tested adding these changes to an AutoPkg recipe but I think it's doable - the biggest pain would be modifying the version key, which I think would require a custom processor. Thought I'd run this idea by you, I'd be happy to work on a PR for it.

I'm not sure if this would make sense to apply the same logic to the .pkg recipe, but it can't be worse than having multiple releases with the same version string..

[hjuutilainen]

Thanks for the suggestions and the info! I would definitely accept a PR for this. Although it would be best if we could do this without custom processors (I've been trying to avoid creating those lately), I don't think it's possible here.

Thinking more broadly, maybe we should add some sort of generic version fixer processor to the AutoPkg core in the future since this is not the only app that uses a questionable versioning scheme...

[timsutton]

Nice trick! Conveniently enough, LooseVersion (and by extension MunkiLooseVersion) will compare 2.78 as less than 2.78a, which in turn is less than 2.78b, etc.