Rockspec for all versions need to update the source url away from using the git:// prefix, which is being deprecated by Github
theresa-clare opened this issue · comments
Github is deprecating the git:// prefix. See this article for more details.
Downloading lanes is failing with the error The unauthenticated git protocol on port 9418 is no longer supported. on Jan 11, 2022 for the single day brownout described in the article. This will continually fail beginning on March 15, 2022 when this change becomes permanent.
The git:// prefix should be changed to https:// or git+https:// in the rockspec of all versions.
rockspec for 3.16.0 honors this.
The rockspec for 3.16.0 might have fixed this issue, but it has other issues. I'm having all my CI jobs fail because it can't install lua-lanes via luarocks. Here is console output from GitHub Actions:
$ luarocks install lanes
Installing luarocks.org/lanes-3.16.0-0.rockspec
Error: Couldn't extract archive /tmp/luarocks_luarocks-source-lanes-3.16.0-0-6872939/lanes.git: unrecognized filename extension
Error: Process completed with exit code 1.
I uploaded rockspecs for versions 3.15.0 and up on luarocks.org. I feel the older versions should be laid to rest :-). Maybe I should even retire them?
I agree that going back and fixing every single version is probably not the way to go, but...
It looks like 3.13.0-0 has a HUGE userbase that is orders of magnitude larger than the other versions (according to https://luarocks.org/modules/benoitgermain/lanes), would it be reasonable to create a 3.13.0-1 version with this fix?
@ozkar99 I think that "HUGE" user base is probably just a function of the fact that it was the latest release for years and years running, in all likely hood relatively few of those will be pinned to the release.
That's not to say quite a few people are going to have trouble with the pinned version. The tricky bit here is that Luarocks pins rockspec versions, so bumping the rockspec to fix the URL will require most people bump their pins anyway. How many of those are going to want to stick with the old release at that point? (Serious question, not a rhetorical gotcha.)
@alerque
I agree that user base seems to be a function of release cadence where most people just stuck with 3.13 (me included)
Although I can't really speak for the majority, for me personally the reasoning is as follows:
Considering that 3.13.0 was latest for years, and the alternative is updating anyway in order to fix but also bumping up 2 minor versions + a couple of years of changes (that's a bit scary to do on a rush to fix the build).
If I could just "update" to the version I know works fine with my current code base vs also bump the library on untested (to me) changes and risk a regression somewhere (this is for me, legacy code that I am not actively working on), id be able to minimize the "area of impact" of the change.
But that aside I totally agree that is sensible to have the users of the library update to latest version, 3.13 is after all 3~ years old, and its not the maintainers job to support and fix it forever and ever in continuity.
P.S.
Thanks for all the hard work the maintainers of this library has put into it, I understand open source is mostly a thankless job and there's a lot of people that feel entitled to changes and support (I can see why my initial comment can read like that), so I wanted to be clear that I do appreciate the effort you folks have put into this, and this is not the case.
Makes sense. Having a rockspec bump for that major version to fix the download issue might be worth the effort.
Done. BTW, what's the difference between creating a 3.13.0-1 and just refreshing the 3.13.0-0 ?
@benoit-germain If you force push the same rockspec version to LuaRocks then all the distros that have it packaged and include validating checksums in their build process (most of them) will invalidate the package and it will need a maintainer to bump it anyway after fiddling around to figure out what happened and make sure the project isn't compromised.