Skip to content

Conversation

@alerque
Copy link
Contributor

@alerque alerque commented Jul 18, 2020

Closes #49.

As far as I can tell this works fine under Lua 5.4, you just have to let it happen. This updates the rockspec (rockrel 1) to remove the upper bounds currently blocking installation on Lua 5.4, then does some housekeeping to expose previously released versions (so they can be installed from Github directly without using luarocks.org if needed). Lastly it adds an SCM version so that any future development activity on master can be used & tested using luarocks from the master branch. Note this SCM rockspec will also make it easier to add CI testing to this repository (which I can contribute later).

This leaves you with 2 rockspecs to publish on Luarocks.org, the -1 release of the current version plus an SCM one.

@alerque
Copy link
Contributor Author

alerque commented Jul 18, 2020

This updated rockspec being published to LuaRocks is the last hold up for being able to release SILE with Lua 5.4 support.

@brimworks
Copy link
Owner

Looking...

Copy link
Owner

@brimworks brimworks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution! I'd like to keep an upper bound, and I'd prefer to not be required to checkin all these old versions of rockspecs. Is that really required?

license = "MIT"
}
dependencies = {
"lua >= 5.1"
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm reluctant to remove the upper bound since minor versions of Lua often change the C API in backwards incompatible ways.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, Lua's release schedule and versioning is less than stellar. That being said 5.3.5 to 5.4 didn't seem to break much this time around. I got kind of frustrated having to track down a bunch of LuaRock maintainers to bump upper bounds for things that I knew worked fine in my project if I patched out the restrictions. I'd prefer running the risk of running into the breakage myself on new versions of Lua than being guaranteed breakage because module authors pre-emptively blocked it.

@@ -0,0 +1,31 @@
package = "lua-zlib"
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't there a better way to do this that doesn't involve keeping around all these old rockspec files?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not that I know of. LuaRocks is kind of a pain in this regard. Having to change file names when the internal version changes does not play well with source control, but this is both a common hack and the most functional one I've seen as far as covering use cases without breaking Git.

@brimworks brimworks mentioned this pull request Jul 19, 2020
@brimworks
Copy link
Owner

I've cloned your branch to my repository and added a commit so there is still an upper bound (not sure how to do that in the context of this PR):

#51

I'm going to do a bit of testing on 5.4, and if that goes well, then I'll push and upload the rock spec.

Again, I appreciate the contribution!

@brimworks brimworks merged commit f66d848 into brimworks:master Jul 19, 2020
@alerque alerque deleted the allow-lua54 branch July 19, 2020 20:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Lua 5.4 support

2 participants