Gltf-blender-io: Removal of 2.79 support

[julienduroure]

Let's have a talk about 2.79 support ...

My thought:

• Removing support at 2.82 release (feb. 2020). That means:
  
  
  
  • change the source of master with result of "strict 2.80", that is master of Blender repo.
  
  
  • Removing circleci tests of 2.79
  
  
• Until then, support 2.79 compatibility for existing feature
• For new features:
  
  
  
  • support of 2.79 when no/low time effort
  
  
  • no time spent to backport new features to 2.79 when this request an effort
  
  

[Vinc3r]

By the way, no later than yesterday I was wondering if I could update my old 2.79 exporter that we still use in production (for now), but the glTF-Blender-IO readme is very shy about 2.79 version : users doesn't really know if this new addon can be used on it (plus, add to this the warning message during the activation This script was written Blender version 2.81.6 and might not function (correctly), though it is enabled).
That's said, it seems to work, but is it still relevant to use the glTF node group which was necessary when using the old addon, or Principled can be used like in 2.8?

[julienduroure]

Thanks for your feedback. We are going to update the README, explaining that the addon can be used on 2.79, even if there is a warning message.

No need to use the node group anymore with this addon, you can use principled shader as in 2.80, for most of features. Cf doc : https://docs.blender.org/manual/en/latest/addons/io_scene_gltf2.html
This doc is for 2.80, but this is almost the same for 2.79

[emackey]

I'm in favor. I think we should put a git tag on the final version that is known to be compatible with 2.79.

There may be more detailed cleanup that can happen, for example I remember something about the way doubleSided is handled so differently in 2.79 that it wasn't completely hidden behind the strict checks, it was a deeper structural change to the way parameters are passed for material export. But this doesn't need to be cleaned up on the first day after 2.79 is dropped.

Also the tests in master are still against 2.81, we should upgrade them to 2.82 (and leave the 2.81 release branch on 2.81).

[donmccurdy]

^Agreed. 👍

[julienduroure]

So, here are some taks to perform when we will remove 2.79:

• [ ] Create a git tag
• [ ] update README to remove 2.79 info, and add a link to the newly created tag
• [ ] Replace all code of addon by code generated by python script in tools/convert_to_strict_280.py
• [ ] Some code can be simplified:
  
  
  
  • [ ] Vertex Color will be only 4 channels, no more check on 3/4 channels needed
  
  
  • [ ] ...
  
  

[scurest]

Replace all code of addon by code generated by python script in tools/convert_to_strict_280.py

convert_to_strict_280.py currently isn't smart enough to tell what version checks to delete

if bpy.app.version < (2, 80, 0):
    "this is deleted"
if bpy.app.version < (2, 81, 8):
    "this is deleted too :o"

[julienduroure]

The result of the script is already the code that is committed to Blender repository, so if this example is somewhere in the code, we have some issues ...

I think we have to be aligned with blender master, that means that master should work with blender master (in case of API change for example)

[scurest]

It seems fine for the bpy.app.version < (2, 81, 8) code to be deleted in Blender master since Blender master is ahead of 2.81.8 and the check would always be false.

But obviously you can't delete it here without dropping support for not just 2.79 but everything below 2.81.8.

[emackey]

But obviously you can't delete it here without dropping support for not just 2.79 but everything below 2.81.8.

Yes, that should be the plan. Code for 2.81 should live on the blender-v2.81-release branch, not behind an if statement in master. The upstream Blender repo doesn't want an addin that's compatible with multiple versions, just compatible with the version to be released next.

So going forward, we should use branches, not if statements, to track releases. Old releases will not be upgraded with new features.

[scurest]

So this issue isn't about dropping support for 2.79, it's about dropping support for everything but the latest Blender development version?

[emackey]

Basically, yes. What makes 2.79 support unique is that it didn't ship with any version of this addon. But we'll put a git tag on the final release here that has 2.79 compatibility.

For all later versions (2.80, 2.81...) any user that downloads those Blender official releases will automatically get a version of this addon bundled with it, that is the "correct" release for that Blender version, and was tested with that version prior to that release. If some user decides to download "old" 2.80 and then slap a copy of the master branch glTF addon in there, there's no guarantee of compatibility, the test suite already let go of version 2.80 and 2.81. Users shouldn't do that. From this issue forward, if a user wants the latest master build of this addon, they will need the latest Blender prerelease from Blender's own master branch to go with it. Otherwise, they should stick to an unmodified official release of Blender that includes this addon.

I think this is common development practice. I don't know of other plugins that ship sprinkled with if checks for 4 or more different releases of the host software, particularly if the host software is nice enough to bundle the plugin officially. There will be separate git branches/tags for separate Blender releases, but these shouldn't change after an official release happens.

Does this plan cause you any grief?

[julienduroure]

Agreed!

[scurest]

Can this be closed now?