Pragmatically, type definition contributions often start incomplete and evolve with type (and Lua module APIs don't change too frequently in general), I originally chose to not add versioning to teal-types definitions, leaving it as a problem for our future selves if/when the problem actually arises.
So far the problem hasn't really arisen, but especially as we start to build more tooling around this repo, I thought it would be prudent to raise this question, so it's still in the back of our minds.
My initial thought was that we could add versioned definitions as "exceptions" on an as-needed basis (e.g. types/foo-1.0/) or even a separate hierarchy altogether for versioned APIs like versions/foo/1.0/.
With the current tl-type rockspec system being implemented, the former option wouldn't be too problematic, since it would generate a package named foo-1.0-tl-type, which I think would work well enough. (Linux distros have embedded version numbers in package names for things like libqt4 vs libqt5, etc. — once APIs are incompatible, they might as well be separate packages.
Pragmatically, type definition contributions often start incomplete and evolve with type (and Lua module APIs don't change too frequently in general), I originally chose to not add versioning to teal-types definitions, leaving it as a problem for our future selves if/when the problem actually arises.
So far the problem hasn't really arisen, but especially as we start to build more tooling around this repo, I thought it would be prudent to raise this question, so it's still in the back of our minds.
My initial thought was that we could add versioned definitions as "exceptions" on an as-needed basis (e.g.
types/foo-1.0/) or even a separate hierarchy altogether for versioned APIs likeversions/foo/1.0/.With the current tl-type rockspec system being implemented, the former option wouldn't be too problematic, since it would generate a package named
foo-1.0-tl-type, which I think would work well enough. (Linux distros have embedded version numbers in package names for things likelibqt4vslibqt5, etc. — once APIs are incompatible, they might as well be separate packages.