What's up with your release tagging conventions?

[andrewpollock]

Hi,

I'm working on doing algorithmic identification of fix commits from the version data in CVE records. See https://osv.dev/blog/posts/introducing-broad-c-c++-support/ (yes, I realise this project is in Java, but what I'm doing is language agnostic, and still relevant to CVEs affecting Apache InLong).

I see that you have releases such as 1.9.0 but the related Git tags are 1.9.0-RC0, which completely confounds the algorithmic mapping of versions to tags, and I also find just generally surprising.

a) why are you doing this?
b) would you entertain making your tags match your release versions? (the benefit to you being you'll get your CVEs showing up in OSV.dev automagically)

[dockerzhang]

Hi, Andrew
the tag which has RC word means release candidate, if the candidate version passed by vote, we will use it as the release tag. if you want to make this more clear and simple, you could use the branch name to match the release version(such as release-1.11.0) other than tags.

[andrewpollock]

Hi @dockerzhang, thanks for getting back to me.

I'd figured the RC tags were release candidates, I was just finding it odd that they applied to actual releases.

The tag resolution code doesn't currently have any repo-specific heuristics (and frankly, I'm not sure that going down that path is a great idea). I'll have to see if introspecting by branch is a feasible alternative to tag resolution (my initial gut reaction is it won't be).

/cc @oliverchang