Longtime support (LTS) exists for a reason in the tech industry. Maybe provide an LTS.
I know why we ended up where we are. I know the history because I was there: with the Lua/LuaJIT schism, people wanted to support both environments, and targeting 5.1 was a good way to support both. And then 5.2, 5.3, etc. came along and people wanted to keep supporting the latest PUC-Rio Lua, but still felt tied to the 5.1 anchor. I’m sure I’m partly to blame for this because I engaged in this and helped others, by maintaining compat-5.3, itself an evolution of compat-5.2, with a history tracing all the way back to compat-5.0, which predates my involvement with Lua… and then we’re talking over 20 years ago.
So I haven’t worked with Lua myself, but is that right? There are forward-incompatibilities in minor versions…? Because that honestly seems pretty fucking stupid. Making basically every version include breaking changes and refusing to follow semantic versioning standards that are designed to essentially account for that is pants-on-head stupid.
Python does it, too. ¯\_(ツ)_/¯
Makes it real fun when one of your dependencies requires, say, Python 3.12 and another breaks on 3.9+.
Python is one of the worst offenders here. I don’t think Python’s poor behaviour should excuse Lua’s.
But I can also see why Python is making breaking changes - a lot of Python is so bad it really makes sense to clean it up. I dunno if Lua is in that situation.
Anyway I think I would look to other languages like Go, Rust, Java, C++ which do a much better job. I don’t think Go or Rust have any backwards incompatibilities (at least very very few) and C++ has a small number but they’re for stuff that is truly ancient or almost completely unused. It’s totally possible if you care about it.
Oh, most definitely.
Several months back I was kinda pulling my hair out over the frustrating state that Apache Airflow was in, because (due to my company’s infosec, SQA, and regulatory policies) I found some delightful mutually-exclusive transitive dependencies when I tried to diverge (with version upgrades to get past CVE-marked releases) the constraints from the officially-packaged constraints.txt. Though, that’s packages, not actual lang level.
Were you around for the 2 -> 3 migration? Now THAT was a categorical shitshow.
refusing to follow semantic versioning standards that are designed to essentially account for that is pants-on-head stupid.
Seems like it would be a bit hard to follow a versioning scheme that it predates by almost 20 years. Lua 5.2 even predates semver 1.0.0.
Before semver there was basically no standardization in versioning schemes and the meaning that semver applied to version numbers basically didn’t exist (at least in my experience) before it came around. Everyone just kinda had their own meaning for what version numbers meant.
semantic versioning wasn’t a new concept when semver 1.0.0 was released. Before that lot of projects already followed this scheme and this was just made official so that everyone should follow it as the standard. So its kind of like if all web browsers support non standard features, and then the committee decides to add it to the standard to make it official. My point is, that the release of semver 1.0.0 isn’t the invention of it.
Ok that’s actually an excellent point that I hadn’t accounted for lol
from https://www.lua.org/versions.html:
The releases of Lua are numbered x.y.z, where x is the series, x.y is the version, and z is the release.
Different releases of the same version correspond to bug fixes. Different releases of the same version have the same reference manual, the same virtual machine, and are binary compatible (ABI compatible).
Different versions are really different. The API is likely to be a little different (but with compatibility switches), and there is no ABI compatibility: applications that embed Lua and C libraries for Lua must be recompiled. The virtual machine is also very likely to be different in a new version: Lua programs that have been precompiled for one version will not load in a different version.I like how there’s no description of what a “series” is.
There doesn’t really need to be as they’ve stuck to the same series for decades now.
Are there migration path for projects embedding a LUA version? Or is LUA incompatible between version?
Like if I build a plugin for a project in LUA 5.1, and the project want to migrate to 5.5, are there forward incompatibilities? Are there API deprecated for long enough to let people migrate?
As an observer I don’t understand why “once you choose a version for your project and a plugin ecosystem develop on it, you are married to this version”.
It’s Lua, not LUA. It’s Portuguese for moon, not an initialism.
You can’t migrate once you’ve got a plugin ecosystem because you’re not the maintainer of all third-party plugins, and the maintainers might have lost interest or died and used a licence that doesn’t let anyone else take over.
And in the mean time I read that there are frequent and apparently non trivial breakage on version.
Not trying to point finger since it is not easy, but thinking about the upgrade strategy of a project (or language) and help consumers of your project (and their plugin) get to the next version would help them on this issue. We have examples of languages doing this (or not). There may be more challenges for an embedded languages (than for Rust or Python) but I’m sure some concepts can still be applied anyway.
To support your point in stylizing the name: https://www.lua.org/about.html
Like most names, it should be written in lower case with an initial capital, that is, “Lua”. Please do not write it as “LUA”, which is both ugly and confusing, because then it becomes an acronym with different meanings for different people. So, please, write “Lua” right!
It’s Lua, not LUA. It’s Portuguese for moon, not an initialism.
I wonder why people do this. Happens a lot with Java too.
I’ve not seen it so much with Java, but for Lua, it’s not an English word, and most things in software are either English words or acronyms/initialisms, so it’s usually a safe heuristic to assume anything that isn’t an English word should be capitalised.
I wonder why people do this. Happens a lot with Java too.
Look at my other reply that explains and links to it: https://lemmy.ml/post/50986115/27084875 or this link https://lemmy.ml/comment/27084875 I’m not sure which type of link to provide, same comment.
