Is Lua 5.1.1 your next executable?? (Re: [ANN] Lua 5.1 Debian package)

[Asko Kauppi <askok@...>]

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