search

luvit / lit

Toolkit for developing, sharing, and running luvit/lua programs and libraries.
http://lit.luvit.io/
Apache License 2.0
245 stars 58 forks source link

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

Closed carlocab closed 3 years ago

carlocab commented 3 years ago

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

https://github.com/luvit/lit/blob/9b0f3be64e9b8dd65bece121ce9a2ae8d8ac1c00/get-lit.sh#L3-L4

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.

squeek502 commented 3 years ago

Yeah, looks like the tagged commit is one commit too early. It should include https://github.com/luvit/lit/commit/84fc5d729f1088b3b93bc9a55d1f7a245bca861d

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.

creationix commented 3 years ago

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

creationix commented 3 years ago

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

carlocab commented 3 years ago

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.

creationix commented 3 years ago

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.

carlocab commented 3 years ago

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.