Is Lua versioning compliant with semantic versioning

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Is Lua versioning compliant with semantic versioning

Dibyendu Majumdar
Hi,

I am watching a talk on CMake - and one of the things the presenter is
talking about (or recommending) is semantic versioning (semver.org).
Made me think that Lua's numbering is not compliant if a minor release
is meant to be signify full backward compatibility. So 5.4 ought be
6.0; and 5.3 and 5.2 ought to have had major version changes too.

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Is Lua versioning compliant with semantic versioning

Coda Highland
On Mon, Jan 20, 2020 at 4:06 PM Dibyendu Majumdar <[hidden email]> wrote:
Hi,

I am watching a talk on CMake - and one of the things the presenter is
talking about (or recommending) is semantic versioning (semver.org).
Made me think that Lua's numbering is not compliant if a minor release
is meant to be signify full backward compatibility. So 5.4 ought be
6.0; and 5.3 and 5.2 ought to have had major version changes too.

Regards

semver is not the only sensible standard for semantic versioning.

Lua follows the older model. The major version number is constrained to only change when there are substantial changes to the design. The minor version number represents what should be interchangeable in terms of compatibility, modulo bugfixes. The patch version number represents bugfixes.

Blindly following semver can result in version numbers that are less meaningful in practice for some projects. It makes different versions of the software look more distinct than they actually are. And it's only really logical at all if the software isn't seeing incrementally added new features -- for something like Lua, you would never see a x.1.x release because that's just not how Lua works.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: Is Lua versioning compliant with semantic versioning

Sam Putman


On Mon, Jan 20, 2020 at 5:32 PM Coda Highland <[hidden email]> wrote:
On Mon, Jan 20, 2020 at 4:06 PM Dibyendu Majumdar <[hidden email]> wrote:
Hi,

I am watching a talk on CMake - and one of the things the presenter is
talking about (or recommending) is semantic versioning (semver.org).
Made me think that Lua's numbering is not compliant if a minor release
is meant to be signify full backward compatibility. So 5.4 ought be
6.0; and 5.3 and 5.2 ought to have had major version changes too.

Regards

semver is not the only sensible standard for semantic versioning.

Lua follows the older model. The major version number is constrained to only change when there are substantial changes to the design. The minor version number represents what should be interchangeable in terms of compatibility, modulo bugfixes. The patch version number represents bugfixes.


I wouldn't say that the change to environments between 5.1 and 5.2 is a compatible change.

I have no complaints with how Lua does versioning, to be clear.
Reply | Threaded
Open this post in threaded view
|

Re: Is Lua versioning compliant with semantic versioning

Coda Highland


On Mon, Jan 20, 2020 at 6:13 PM Sam Putman <[hidden email]> wrote:


On Mon, Jan 20, 2020 at 5:32 PM Coda Highland <[hidden email]> wrote:
On Mon, Jan 20, 2020 at 4:06 PM Dibyendu Majumdar <[hidden email]> wrote:
Hi,

I am watching a talk on CMake - and one of the things the presenter is
talking about (or recommending) is semantic versioning (semver.org).
Made me think that Lua's numbering is not compliant if a minor release
is meant to be signify full backward compatibility. So 5.4 ought be
6.0; and 5.3 and 5.2 ought to have had major version changes too.

Regards

semver is not the only sensible standard for semantic versioning.

Lua follows the older model. The major version number is constrained to only change when there are substantial changes to the design. The minor version number represents what should be interchangeable in terms of compatibility, modulo bugfixes. The patch version number represents bugfixes.


I wouldn't say that the change to environments between 5.1 and 5.2 is a compatible change.

I have no complaints with how Lua does versioning, to be clear.

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.)

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: Is Lua versioning compliant with semantic versioning

Scott Morgan
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

Reply | Threaded
Open this post in threaded view
|

Re: Is Lua versioning compliant with semantic versioning

Coda Highland


On Mon, Jan 20, 2020 at 8:37 PM Scott Morgan <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Is Lua versioning compliant with semantic versioning

Jerome Vuarand
In reply to this post by Dibyendu Majumdar
On Mon, 20 Jan 2020 at 22:06, Dibyendu Majumdar <[hidden email]> wrote:
> I am watching a talk on CMake - and one of the things the presenter is
> talking about (or recommending) is semantic versioning (semver.org).
> Made me think that Lua's numbering is not compliant

It is clearly not compliant.

> if a minor release
> is meant to be signify full backward compatibility.

Semantic versioning doesn't define what compatible means. So all it
does is create expectations that will later be broken. That's just
trolling (albeit a insidious form of it).