Release

[florrain]

Hi there,

Wondering if you were planning a new official and stable release soon? That would just make production setups way safer with more warranties of stability versus using the latest master. Lots of libraries are also relying on luasocket and nothing has changed for 2 years now.

Best,
Thanks

[diegonehab]

I agree we should release a version. But things are changing every now and then. Sometimes in a significant way.

[mpeterv]

Would it be possible to create a new branch (called v3.0-rc1.x?) from v3.0-rc1 tag, cherry pick only fixes from master and tag a new release on that branch?

[florrain]

For sure. We can all rely on the semantic versioning for that reason and use major versions when you're in that position.

Also I know this is out of subject here but in case you know somebody has ever used this library with HAProxy, I'd be interested in the revision or version (rc1?) he/she used.
Have this error when loading socket.http (LUA 5.3.1, HAProxy 1.6.3, latest master from this repo):

[ALERT] 040/151350 (790) : parsing [haproxy_ksa.cfg:4] : lua runtime error: error loading module 'socket.core' from file '/usr/local/lib/lua/5.3/socket/core.so':
    /usr/local/lib/lua/5.3/socket/core.so: undefined symbol: lua_gettop

Thanks again 👍

[siffiejoe]

@florrain: I suspect that HAProxy doesn't re-export the Lua symbols from its executable. Lua modules on Unixes expect that. If HAProxy links to liblua.so, one alternative would be to link your socket.core to liblua.so as well, but that would make the module incompatible with the normal Lua interpreter (and I think LuaRocks doesn't support this mode of operation anyway). You could also try to re-export the symbols from the shared library using some FFI interface like in this stackoverflow answer.

[florrain]

Thanks @siffiejoe that's helpful. I'm not sure how to actually do these steps but I'll look into it.

[siffiejoe]

@florrain: The developers of HAProxy should fix this by using the -Wl,-E flag when Lua is statically linked to the main executable, or by loading the Lua API from the shared Lua library with RTLD_GLOBAL otherwise. However, I've just released a small module which tries to fix the Lua API export issues. I've tested it on Linux, but it should work on other Unixes as well (BSDs for instance). It's also on LuaRocks, but only in the DEV manifest for now. You'd have to require it before any other C based module.

[Neustradamus]

Linked to #93

[alerque]

I'm going to close this because I don't see anything very relevant that needs to be reviewed specifically for the next release cycle. I'm going to push through a release sooner rather than later (100% done or not) to get the Lua 5.4.3+ fixes into something with a tag on them, but I don't think having a bunch of tracking issues asking "when release" is helping.

The only thing here I think we need to consider is what version (semantically speaking) to call a new release at this point. But I think that will belong in its own issue anyway.