Gltf Extensions should be split into 1.0 and 2.0 folders in the repo

[chipweinberger]

I just spent 10 minutes trying to figure out why KHR_materials_common seemed so 'off', only to later realize its only for 1.0. This should be reflected in the folder structure.

Extensions/1.0/Khronos/KHR_materials_common

[Kupoman]

What about extensions that are compatible with multiple versions of glTF. Would they be duplicated across folders?

[chipweinberger]

That's best and most clear, yes. 1.0 is basically dead. It's there for legacy and should not be worked on or updated anymore. So we should copy whatever extensions support 1.0 right now into the 1.0 folder, and forget about them. As a once time exception, if the extension supports both put it in both. But going forward extension spec changes intended for gltf 1.0 should probably be prohibited. Any new extensions or updates to extensions should only be allowed in the 2.0 folder.

As for another more important edge case, take KHR_material_common. A 2.0 version is being worked on for gltf 2.0, but there will still be the 1.0 version that has some amount of use use.

Thanks for the comment, that was a good question.

[donmccurdy]

+1 for splitting extensions into 1.0 and 2.0 folders.

When we moved from glTF 1.0 to 2.0 the extensions did not "roll up", and we've been gradually defining the 2.0 versions. I'm assuming that for any glTF 2.X releases, the 2.0 extensions remain valid? Not sure if there's a precedent on this yet, but that would be my vote.

[pjcozzi]

I agree with @donmccurdy on both points. Will run it by the Khronos working group tomorrow.

[pjcozzi]

Also, thanks for bringing this up @chipweinberger!

[donmccurdy]

Here's a PR: #1214

About whether extensions "roll up" with 2.X releases, it is our current expectation that the 2.0 extensions remain valid, but this could depend on details of the (hypothetical) 2.X change and extensions involved.

[pjcozzi]

@chipweinberger thanks for bring this up. #1214 was merged.