4 ms·
Problem is, which version of love to use? I do know someone had a multiversion love program but it didn't work for me.
by nmz 3y ago
Problem is, which version of love to use? I do know someone had a multiversion love program but it didn't work for me.
- akkartik 3y agoCould you point me at it? Just for my own understanding.
- nmz 3y agoI think its this but I am unsure. https://github.com/Alloyed/flirt https://github.com/Alloyed/flirt
- akkartik 3y agoI just looked at this. It feels awfully brittle. My goal at the moment is to try to support every version of LÖVE going forward. All my apps work with any version after 11.0. Hopefully that streak won't be too onerous to continue in the future. Here's how my apps' version check works, based on suggestions from the LÖVE Discord (but mistakes are mine): https://git.sr.ht/~akkartik/template-live/tree/9cddb20b96aa1beaeee4c5d8aa9f5ac67a859724/item/main.lua#L45 https://git.sr.ht/~akkartik/template-live/tree/9cddb20b96aa1... I don't use t.version in conf.lua anymore in Freewheeling Apps (though my early apps are not perfect)
- nmz 3y agoI've never used love. It's certainly difficult if you're going with portability, and then add to that backwards compatibility. I've talked about this before, but I think the only way to do versioning is the way everyone does it nowadays. Have a directory, with a wrapper around the dvcs/(Commits/ Tags/) and then a subdirectory for a "git workingset", And then you Import("url",{tag="",commit="",req="x.y.z"}), it should be fast because you're just doing io.open($REPOHOME/$URL/TAG/$TAG/$COMMIT/x/y/z) which just gets dropped to require() as normal. of course, add LÖVE to the mix and I just don't know. love should have mandatorily a love-VERSION as the command.