API stabilization

[pgimeno]

I very recently discovered LÖVE and inevitably fell in love with it. But soon I discovered that some 60-80% of the stuff made with love2d that I could find only works with an older version.

That has raised a deep concern in me. We are working on projects that may be broken one or two releases from now. The ground shakes under our feet, and some stability to rely on would be great. It's nice to have a final release with a well-designed API, but given the popularity of LÖVE at this time, it would be good to start worrying about backwards compatibility and less about impeccable design.

So my question is, is there any target release where the API should be stable, that is to be expected any time within a year or two? I've been looking for roadmaps and found none so far, besides a fun picture; the only serious answers I found pointed to the issue tracker.

[Jasoco]

1.0 will be stable.

Until then things change.

1.0 does not have a release date.

There's plenty of documentation for porting. And older versions can still be found if you need them.

The next version is 0.10.0. After that will probably be 0.11.0.

[slime]

LÖVE's point releases (0.9.1, 0.9.2, etc.) contain no intentionally breaking API changes and are designed to be backwards-compatible with code written for the initial 0.x.0 release.

The 'minor' version (0.9.0, 0.10.0, etc.) releases are not backwards-compatible. I think it's pretty reasonable for it to continue to be like that, considering such releases take 1-2 years to come out.

In fact, I don't know of any game library, engine, or framework that maintains backwards compatibility for all of its releases. Unity, UE4, XNA, libgdx, SDL, etc. all have version releases which contain breaking changes that aren't backwards-compatible. The realities of game creation tool development necessitate this, I think.

LÖVE 0.10.x and 0.9.x and 0.8.0 are just as stable as a 1.0 release would be – they're just different targets that you can choose to base your game code on.

If a LÖVE 1.0 release would happen I wouldn't count on all post-1.0 releases remaining backwards compatible. Doing so would eventually make LÖVE's code unmanageable and prevent its API from meeting the needs of users.

[Jasoco]

When Löve first came out it was primitive and even the libraries it used were limited in many ways. As time goes on, new features are thought of. Functions are optimized. Libraries gain new features. It's understandable to expect the API to change a lot between big releases.

I came in at 0.5.0 and my god, if you went back to that now, there was so much it could not do at all. 0.6.0 was a pretty big update when it came along but it was worth the trouble of porting just to have the new stuff. And a bunch of stuff 0.6.0 brought has been removed by now and replaced with other stuff. Things change. We used to need a separate draw call for images and quads. Now it's the same call and it's automatic. And it can be made backwards compatible with a simple love.graphics.drawq = love.graphics.draw in your main file. (Or localized to every lua file where you'll be using images) But really in the end it's just easier to locate and replace all drawq calls. Not everything can be easily ported, but all it takes is a bit of Wiki perusing and Forum asking to fix it when a minor update comes along.

It would suck if 0.5.0 was what we were stuck with now. So much stuff has been added to Löve since then.

[miko]

That has raised a deep concern in me. We are working on projects that may be broken one or two releases from now. The ground shakes under our feet, and some stability to rely on would be great. It's nice to have a final release with a well-designed API, but given the popularity of LÖVE at this time, it would be good to start worrying about backwards compatibility and less about impeccable design.

So, you have found examples from several years ago and you worry that it does not work with the latest released version (0.9 released on December 2013, 0.9.2 released on February 2015)? I suggest you to start with (not yet released) 0.10.0 as it does support android/ios, so you will have about 2 years of stable API. BTW, I hope 0.11 will have GPS/microphone/camera API

[pgimeno]

Thanks for the answers. Since I posted and saw your replies, I've been considering working on a patch that would make LÖVE emulate past versions to a certain extent of compatibility. I found this thread which would be a start: viewtopic.php?f=5&t=76993 but from my reading of the wiki, there seem to be quite a lot more functions that need inclusion for backwards compatibility.

At first, I thought of just making a Lua module that you could put in main.lua, but soon I realized that there would need to be both in love.conf (to declare 'screen' for certain versions) and in main.lua (to actually do the patching to all modules that require it). But it's obviously easier to do all that from boot.lua itself.

My idea is to let the user define which exact version of LÖVE to emulate (perhaps using an environment variable, perhaps something like 'love --emulate=0.7.2' or similar).

That system would keep the API clean when not requesting to emulate a previous version, and provide a decent level of compatibility. The "might not work" sign would stay, because indeed some things may be too difficult to emulate accurately, but it would drastically increase the number of programs that would run. If you actually take a look at the games you can find with https://github.com/search?utf8=%E2%9C%93&q=love2d+game you may notice how spread the bit rot virus is. Only a few do work. I hope that this would change the stats.

The big problem is that I'm completely new to LÖVE and it would take a lot of research to find all the changes necessary. I'm not sure whether I'll give up before there's something working.

[Germanunkol]

I would advice against such an emulator. It would be very difficult to maintain and would not be worth the trouble, imho.

There are three "audiences" for your game, I believe:
1. Gamers on Windows/Mac: For them, you simply pack the game with whatever version it's made for.
2. Gamers on Linux: They're used to "making" their packages compatible - i.e. by installing the version needed for your game, or compiling it from source.
3. Other devs: They'll be used to having two versions of Löve around, and will forgive you if the game's not compatible to one of them.

With that said, you CAN check the version of Löve which a game is running on (check out love.getVersion().
This way, you may be able to disable features in your game if they're not available with the current version you're using, or exit gracefully, with a nice message asking the user to get the correct Löve version. You can even overwrite functions or add them to change the API to fit your needs (and fit the other Löve versions) in many cases. This would be way easier to maintain than a full emulator, where you'd need to think of every possible use-case; even things your game doesn't even use.

I've had to port a game or two from older versions, and usually it was around half a day of work, maximum.

[Inny]

I'm of the opinion that trying to do some strange patchwork of mismatched versions within software is the road to madness. It's bad enough that we don't even test our software on enough of the hardware platforms that it will run on. Your best bet with love for wide distribution of a game is to ship love.exe with the game.

As for porting code between versions, as that can be quite different and difficult, I can suggest doing the backwards-version of polyfills (like javascript developers like to do). Whatever functions on the old API versions which are no longer available, but can still be done with the new API functions, you write a function to simulate the old functionality.

This is a terrible example:

Code: Select all

do
  local _push = love.event.push
  love.event.push = function(e, ...)
    local _e = e == "q" and "quit" or e
    _push(_e, ...)
  end
end

However, you probably should be _very_ conservative with how you do this. In my terrible example, it might have been better just to fix the offending code rather than monkeypatch the API.

[miko]

My idea is to let the user define which exact version of LÖVE to emulate (perhaps using an environment variable, perhaps something like 'love --emulate=0.7.2' or similar).

If you would like to have better results in less amount of time, I would suggest different approach - after recognizing the game version and user's OS, if the versions do not match - link user to the love binary for this game on this platform. If you were able to to it under-the-hood (like downloading executable, possibly using cached version, contatenating current *.love with it, and making a *.sh or *.bat script to run it), that would be a one-click solution which would be easy enough for users.

[pgimeno]

So the general opinion is that it's not a good idea and that instead, the correct version should be installed and run, by whoever wants to run the application/game.

Now this is my case. I'm using Debian Wheezy (oldstable) which comes with love 0.8.0. I can't upgrade my OS yet, for a number of reasons, which means I can't install all the libraries required for compiling the development version. I've installed 0.9.1 from Jessie, though, which is what I'm using at the moment. But due to how Debian's packaging system works, I can't install several versions side-by-side. So how do I handle that? I try a program from a random search in GitHub, and I have no clue which version it needs because it doesn't include a version specification in conf.lua; should I install them all? Do all old versions work with current libraries?

My simple objective is that what I code will keep working in future without me needing to learn the changes and adapting it to the new version. It's sad to think that that's asking too much. As a little background on myself, I wrote one of the first ZX Spectrum emulators, back in a time where emulating another machine was something rarely heard of, because I was concerned that it would stop working. Now I can play any game made for that computer, but paradoxically it seems that the games I make with LÖVE can't resist the passage of time so well.

I would much prefer to push for stabilizing the API and getting a sort of "LTS" version than to go the route I suggested. But I also understand free software development and volunteer work, which is why I thought that I should not try to get others to do it but instead look for a solution that is within my own hands, and contribute it in case it's helpful for others. I'd be happy if the option of making a more stable API is given some consideration, though.