• gravitas_deficiency@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    17
    ·
    2 days ago

    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.

    • trem@lemmy.blahaj.zone
      link
      fedilink
      arrow-up
      14
      ·
      1 day ago

      Python does it, too. ¯\_(ツ)_/¯

      Makes it real fun when one of your dependencies requires, say, Python 3.12 and another breaks on 3.9+.

      • FizzyOrange@programming.dev
        link
        fedilink
        arrow-up
        5
        ·
        1 day ago

        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.

      • gravitas_deficiency@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        1 day ago

        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.

    • azdle@news.idlestate.org
      link
      fedilink
      arrow-up
      19
      ·
      2 days ago

      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.

      • thingsiplay@lemmy.ml
        link
        fedilink
        arrow-up
        12
        ·
        2 days ago

        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.

    • kirisamemarisa@lemmy.eco.br
      link
      fedilink
      English
      arrow-up
      10
      ·
      2 days ago

      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.