Re: Lua and backwards compatibility - was Re: [ANN] Lua 5.3.4 (rc2) now available,

[Dibyendu Majumdar <mobile@...>]

Hi Tomás,

On 12 January 2017 at 14:12, tomas <tomas@tecgraf.puc-rio.br> wrote:
> I work with Lua since 2.1 days and my team maintain code developed initialy
> with CGILua 3, 20 years ago, and were converted/upgraded to every new Lua
> version until 5.2 (we are planning to upgrade to Lua 5.3, but we have to
> wait for the libraries: CGILua, LuaFileSystem, LuaSQL, LuaExpat, LuaSOAP,
> LuaSec, LuaSocket, CGILua LuaZip, lua-iconv, LPEG, HTK, Dado).  So we did
> many upgrades and converted our code many times.  Maybe our case is too
> particular to generalize, but that task was always a simple and easy task.
>

Would it not be better though if you could upgrade to the next version
without having to change things?

I think there are other problems than just upgrading your code.

Firstly, I see that many libraries are still on 5.1 and so many people
have not bothered to upgrade. Unless you are full time working on
maintaining your Lua code (which it seems you are) then it may be
difficult to keep supporting different versions.

Secondly - and I think this is a bigger pain point - you need to build
multiple versions of your library as one library cannot support
various Lua versions. This issue is quite a tragedy I think. For
instance I get requests to support 5.1 in my VSCode Lua 5.3 debugger.
I cannot do so without creating another extension dedicated to 5.1.
Whereas ideally my debugger should just be able to run 5.1 code.

In my post I suggested providing strong backwards compatibility from
5.3 upwards, only because I think as far as the 5.2 and 5.1
compatibility story is concerned, the 'horse has bolted' so to speak.
In fact, I think there ought to be a concentrated effort to bring back
/ support as much of 5.1 and 5.2 as possible - to enable more people
to upgrade to 5.3.

> I think the Lua team always made a good judgement when faced with the
> problem of introducing a new feature and also an incompatibility.  I don't
> think this should be changed.
>

I think that it is possible to evolve the language without breaking
compatibility. Just look at how much C++ has evolved since 1998, and
yet all the old code still works. It requires more effort and thought
- and sometimes things don't look so nice but that is a price worth
paying.


Regards
Dibyendu