lua-users home
lua-l archive

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



Wait a minute.

There now seems to be consensus on also LuaBinaries moving to "lua5.1" naming instead of "lua51", is there?

Technically, I don't mind, but is there really any benefit for this? If the Lua authors would warrant, as is the case with Lua 5.0.2, that any 5.1.x version is ABI and API compatible with 5.1, there's basically no issue.

Personally, I'd favor having lua51 for anything Lua 5.1.x series will bring. Am I the only one seeing Things How They Now Stand as being rather good? Which I do.

Worried.. just a bit.
-asko



John Belmonte kirjoitti 7.2.2006 kello 4.01:

Antonio Scuri wrote:
At 01:18 27/1/2006, John Belmonte wrote:

Naming convention (lua5.1 vs. lua51)
------------------------------------ The naming convention prior to
the lua5.1 package, specifically the lack of delimiters in the
version portion, lacked foresight.  The reason is that if the
version ever has more than one digit per component, the terser name
will be ambiguous.  Even if this will never be a problem in
practice (will 61.1 clash with 6.11?), lua12.3 seems more friendly
than lua123.


This is something that we can do in LuaBinaries, so we can maintain
compatibility between LuaBinaries and the Debian package.


Library SONAME -------------- As explained, each series of Lua
(e.g. 5.0, 5.1) is treated as a completely separate library.
Within a series, Libtool versioning is followed.  For example, the
first release of Lua 5.1 (5.1.0) will have a soname
"liblua5.1.so.0".  Let's say that 5.1.1 is later released, and it
is binary compatible with the previous version.  In that case, the
soname will stay the same, and existing applications do not need to
relink. Note that in this convention, along with the naming of
interpreters, etc., as described previously, there has been a
conscious compromise in the granularity of the versions that may be
specified.  That is, the minor version number is considered
significant in that it may break compatibility, but not significant
in calling out a version of Lua to interpret a file, maintaining
parallel versions for development, etc.


This is complicated for us. We do not use libtool, and library names
are simply "lua<version>.lib" (in Windows) or "liblua<version>.so/.a"
 (in UNIX). And in UNIX everything can be solved with a file system
link.

In the liblua5.1-0-dev package:
  /usr/lib/liblua5.1.a
  /usr/lib/liblua5.1.so  (symlink)

so I don't think this is incompatible with what you say. Note, however,
that the .so with the soname number ("liblua5.1.so.0") should be used
rather than the symlink above.  If you link against the symlink, and
there is a binary incompatibility in the 5.1.1 release (e.g. C API
signature change) you could get a run-time error in packages built
against the old release. (To my knowledge, there is no promise from the
Lua authors regarding C API compatibility in a minor release.)  These
are the kind of issues that large Unix distributions have to be
concerned with.

We were using <version> as "51", but it seems to be reasonable to
change to "5.1". Any comments?

Note that the "Naming convention (lua5.1 vs. lua51)" rationale above
applies to all Lua related filenames, not just the command line interpreter.

--John