About v1.2.0-pre.1 release about gop HOT 5 CLOSED

It's a pre-release, but should be stable in most case.

from gop.

make sense, @xushiwei can you mark the release as pre-release then? it would help at least homebrew to consume the release info. Thanks! 🙏

from gop.

done

from gop.

Thank you!

from gop.

What I'm saying is that I don't see any evidence that upstream creates releases using a stable tag (e.g., 1.2.3) and marks it as "pre-release" before it's stable/released (removing the "pre-release" status when it's released). That's what the livecheck block comment is explaining but that isn't the situation in this repository (unlike the other formulae using this comment).

Looking back at previous snapshots of the GitHub releases page, the issue is that upstream creates GitHub releases for unstable versions (e.g., v1.2.0-pre.1, v1.1.0-rc3, v1.1.0-alpha3) without marking them as pre-release. In this scenario, if upstream doesn't reliably mark unstable releases as "pre-release", GithubLatest may return an unstable version or an Unable to get versions error. Like you, I don't have much faith that upstream will reliably mark unstable releases as "pre-release" (like they've done for v1.2.0-pre.1) going forward.

As mentioned above, checking the Git tags using the standard regex 1) avoids unstable versions and 2) won't run into any issues with upstream's poor irregular process (i.e., failing to mark an unstable release as "pre-release" won't affect livecheck's output). I agree that upstream isn't careful about releases but the solution is to check the Git tags using a stricter regex (to avoid the v1.2.0-pre.1 tag). GithubLatest isn't appropriate in this context and it's likely to lead to further issues rather than fixing this.

Add @samford's comment for the future ref. 🙏

from gop.