LÖVE

I was wondering if a compatibility version system could be adopted? It doesn't have to be the way I describe, just a way that helps prevent compatibility problems on the developer and user ends. Right it seems a bit painful to maintain 10-different versions on 1 system, and for developers to make a game that will stay up-to-date.

I'm thinking something along the lines of:
- Backwards compatibility in the same Major version. Ex: 1.9 can play 1.2 games; 5.0 can NOT play 1.2 games.
- Backwards compatibility with 1 Major version prior. Ex: 2.5 can play 1.2 games; 3.0 can NOT play 1.2 games.
- A system to automatically remove deprecated engine functions from the dev source code, for the sake of allowing devs to use the latest code only. Maybe just a comment at the deprecated functions "This function is deprecated. Use new function instead: ________". Maybe it could work based on the concept of inheritance somehow until things are replaced completely.

I'm not even entirely sure of the current version system, as it seems nearly every minor or even sub-minor version is incompatible with the last.

I see there were other attempts to mange versions, but I just see them as workarounds:
https://love2d.org/wiki/Adult_Lib
viewtopic.php?t=81473 (Flirt)

Please consider figuring out a way to manage compatibility between versions better. It is a problem, especially when considering some of the platforms the games run on (Android), and just the overall hassle of downloading many versions to have all games work.

MajorLunaC wrote:I was wondering if a compatibility version system could be adopted?

Currently all patch releases of LÖVE (where a version is major.minor.patch) are backwards-compatible with code written for previous versions of the same minor release. For example, [wiki]0.9.2[/wiki] and [wiki]0.9.1[/wiki] are both backwards-compatible with code written for [wiki]0.9.0[/wiki].

In 0.9's case, it meant there was no release that removed backwards-compatibility for two years (December 2013 to December 2015).

Keep in mind too much backwards-compatibility causes APIs to become awful over time and stifles useful changes (especially internal changes). After a certain point it's just not feasible to retain legacy code paths, and the chances of those codepaths causing things to break – and the burden on the LÖVE developers to make sure the old code is still functional – increases with every change to the codebase.

MajorLunaC wrote:Maybe just a comment at the deprecated functions "This function is deprecated. Use new function instead: ________".

LÖVE [wiki]0.9.1[/wiki] and [wiki]0.9.2[/wiki] deprecated several functions which were eventually removed in [wiki]0.10.0[/wiki]. Most of LÖVE's functions are defined in C++ though, so you can't really write a comment there that people will see. The deprecated functions did have a large deprecation notice at the top of their wiki pages.

Ah, so it's a decimal off, but otherwise mostly as already said. Two years is alright actually, although performance and functionality should not be compromised too much. Good games can take quite a while to make, so it would be bad to find lots of changes by the time you finish.

Considering the engine is so small, it could even be packaged with it, as a good way to have things work. People could always delete it if they don't need it.

MajorLunaC wrote: Considering the engine is so small, it could even be packaged with it, as a good way to have things work. People could always delete it if they don't need it.

For windows and mac that is usually done (check Game_Distribution on the wiki). On linux its possible in the same simple way in theory, but because of the diff possible architectures, smaller market and general tech-savvy-ess of users people usually ship .loves. But you can bundle it with the engine and distribute it on steam for example.

I started a project in 0.8, then ported it to 0.9, and now again to 0.10. It's not really that bad of a process (I think 0.8 to 0.9 was worse, but 0.9 to 0.10 was a breeze). The only really annoying part is if libraries you're using break, but even a lot of the libraries posted here are pure lua, so version won't matter to them.

0.5 to 0.6 and 0.6 to 0.7 were much worse. Especially from 0.5 to 0.6.