Lua 5.4 support about lua-zlib HOT 10 CLOSED

@carlocab Lua is somewhat confusing in this area. There are two release version metrics at play here: the code version and the luarocks release version. It is not uncommon to bump the latter to update package meta data on luarocks.org without making any changes to the actual payload / code in the project. That's what happened here. The code tagged as 1.2 already is Lua 5.4 compatible but the meta data file that gets uploaded to the package archive was suggesting it wasn't. Since only the meta data file got changes, only the rockspec release number got bumped. If you install from LuaRocks now what you will get is 1.2-1 instead of 1.2-0. Note that version scheme isn't even a tag here on Git, according to the code the software version is just 1.2.

For convenience there happens to be a copy of the meta data file here in the repo, but it doesn't need to be part of the tagged release. It wouldn't normally be used at all, and if it was you would reference it by it's full URL relative to master not relative to the tag. For most purposes either downloading the code archive from the tag manually and running luarocks make (which despite its name is actually an installer and doesn't use the remote meta data to function at all) or doing the download automatically using luarocks install (in which case you will get the up to date remote meta data) are the two ways to get the job done and both now support Lua 5.4.

from lua-zlib.

Sounds great to me! PRs are welcomed. I hadn't even seen the 5.4 announcement.

from lua-zlib.

Rockspec has been published: https://luarocks.org/modules/brimworks/lua-zlib/1.2-1
Tag for v1.2 has been updated: https://github.com/brimworks/lua-zlib/releases/tag/v1.2

Let me know if you need anything else done.

Thanks for the contribution!

from lua-zlib.

Oy oy oy please don't change tags like that! Release v1.2 was tagged in 2017 on a305d98 and should remain there. Anything newer needs to be a different tag or you break not only everybody's fork workflows but also all the old releases for distros! Now for example Arch Linux users can't rebuild the package for 1.2 even using Lua 5.3 like they could before because the checksum changed because you moved the tag. Version tags shouldn't be moving targets. What should happen is either a new release (say v1.2.1 or something like that or in this case since the only change is in the rockspec not in the actual code you could even just make a new rockspec file and bump the rockrel to 2 and push that to luarocks without adding a new Git tag at all.

from lua-zlib.

Okay, I reverted the tag back, but don't I need to update the tag in the rockspec?

from lua-zlib.

@brimworks I don't think you need that in this case, once somebody uses the new rockspec (which is where the upper limit was) from Luarocks or from the rockspecs archive dir it can use the old v1.2 tag to fetch the actual source. If the rockrel is the only thing being bumped, you don't need a new git tag.

from lua-zlib.

If anything besides the rockspec needs to change that would mean bumping the version, not the rockrel. And then yes you would want a new tag and a new rockspec file, etc.

from lua-zlib.

Hi there, do you have a timeline in tagging a new release for lua-zlib that supports Lua5.4?

Homebrew needs it in order to upgrade the packaged version of sile, as it builds against your latest release.

from lua-zlib.

Ok, maybe I just misunderstood this. It seems that I just need to rename the rockspec? (Apologies; I don't actually use lua personally, and had a couple of other build errors to diagnose so didn't have the bandwidth to look at things carefully.)

from lua-zlib.

Ok, what the current formula does is renames the tarred lua-zlib-1.1-0.rockspec into lua-zlib-1.2-0.rockspec. Based on your response, I actually need the contents of lua-zlib-1.2-1.rockspec and not just the filename, correct?

Guess I have to go work out how brew resource blocks work.

Update: It works! Sorry for my silly questions.

from lua-zlib.