Mistaken Luvi and Lit versions in `get-lit.sh` on 3.8.5 branch?

The Makefile for Luvit 2.18.0 does

curl -L https://github.com/luvit/lit/raw/3.8.5/get-lit.sh | sh

However, this version of get-lit.sh specifies

lit/get-lit.sh

Lines 3 to 4 in 9b0f3be

    
           LUVI_VERSION=${LUVI_VERSION:-2.10.1} 
        
           LIT_VERSION=${LIT_VERSION:-3.8.1}

Is that right? Or should that be

LUVI_VERSION=${LUVI_VERSION:-2.12.0} 
LIT_VERSION=${LIT_VERSION:-3.8.5}

?

I'm asking in relation to the update of Homebrew's Luvit to version 2.18.0 at Homebrew/homebrew-core#80216.

Yeah, looks like the tagged commit is one commit too early. It should include 84fc5d7

Looks like there's a few slightly messed up things with this release, so we'll probably end up needing to release something like Luvi 2.12.1, Lit 3.8.6, Luvit 2.18.1 pretty soon to get everything congruent again.

For now I moved the lit tag to the correct commit. That should help for now.

I don't know if the github release zip files need updating or not, but it should fix the get-lit url at least.

Thanks.

By the way -- moving tags around isn't great for your consumers downstream. The Git docs even have some pretty strong words about re-tagging.

It'll cause issues for anyone (typically package managers) who uses the commit hash (or tarball checksum, if they download a GitHub tarball) to verify source integrity. (Here's an example.) It's also not convenient for anyone who previously had your repo checked out and wants to look at the 3.8.5 tag.

It's also not convenient for anyone who previously had your repo checked out and wants to look at the 3.8.5 tag.

I thought git would just move the tag when you pull like it moved a branch head? It's not as bad as force-pushing new commits that break history right?

Though reading that document in the docs, it looks like they changed the behavior because people like to think of tags as immutable when they really aren't.

I thought git would just move the tag when you pull like it moved a branch head? It's not as bad as force-pushing new commits that break history right?

git won't move the tag with git pull. If someone had the old 3.8.5 tag, they would need to delete their local tag first and then fetch your new one. (See docs I linked to above.) It's not as bad as force-pushing new commits, but you should probably leave some documentation around about having re-tagged 3.8.5 to make sure users aren't inadvertently using the old one from an existing clone.

	LUVI_VERSION=${LUVI_VERSION:-2.10.1}
	LIT_VERSION=${LIT_VERSION:-3.8.1}