lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]




On Mon, Jan 20, 2020 at 8:37 PM Scott Morgan <blumf@blueyonder.co.uk> wrote:
On 21/01/2020 01:17, Coda Highland wrote:
>
> Sorry, my phrasing was awkward. I meant to say that this was an
> incompatible change, because the minor version number changed. However,
> it wasn't a substantial change to the overall design of the language,
> which has been fairly stable since 5.0; most 5.1 code will still run on
> 5.4 unmodified. (Of course, there will be code that breaks, but it's a
> minority proportional to the sum total of all Lua code.)
>

Isn't the issue here that there are two forms of compatibility being
talked about? 'Script language' and 'library API'.

For comparison, C and C++ compilers don't tend to talk about the
language spec in their version numbers.

On the other hand, the Lua method of <lang>.<api>.<bugfix> makes sense
if you're aware of it (you're unlikely to see the language change
without also changing the API). But I can see package maintainers being
confused.

Scott


I'm not sure if that's the issue or not. It's AN issue, to be sure, but I don't think that distinction actually helps make an argument about semver. If anything, it reinforces the notion that semver isn't appropriate for all projects.

Package maintainers are going to be confused regardless because, to use Gentoo terminology, new minor versions of Lua are separate slots. Not only is 5.2 not a direct drop-in upgrade from 5.1, both versions are likely to be useful at the same time. It's a lot like the Python 2 vs Python 3 thing, except there's not millions of people with opinions on the matter. Debian ships Python 2 and Python 3 as completely unrelated packages instead of listing them as versions of each other.

I think semver is well-intentioned, and I think that it's good to keep the idea of semantic versioning in mind when releasing software, but I think it puts the emphasis in the wrong place -- you shouldn't strive to keep version numbers in sync with the software; you should strive to maintain software compatibility until you have a good reason to bump the version number. This is exactly how Qt did it, and as a result the migration from Qt4 to Qt5 was nearly painless for most applications. (Debate about QtWidgets being marked as "deprecated" despite its successor never being completed are off-topic for this thread.)

/s/ Adam