Tag release with build number instead of short hash

[DannyDaemonic]

Better versioning for the releases has been requested multiple times in the past. In issue #2292, I had suggested using the build number (instead of the date as originally suggested) and got a thumbs up from ggerganov. That said, it was a month ago, so I hope this is still an acceptable solution.

I tested this on my fork (it took a couple tries) but it seems to work now.

The only change we might want to make is to put something in front of the build number for the release tag. (The release files still start with "llama".) I checked other repos and a lot of them just put their version number (0.8.3-beta or 1.0.2) but if just 1032 feels strange, we could instead use something like build-1032 and it would still be sortable and easy to tell which was newer just by looking:

-          tag_name: ${{ steps.tag.outputs.name }}
+          tag_name: build-${{ steps.tag.outputs.name }}

[longregen]

v0.0.0-{build number}, 0.0.0-{build}, and/or following https://0ver.org/ are acceptable alternatives. Being such a dynamic project, I believe there should be no expectation of support for previous minors (in the https://semver.org/ sense). I consider build-NNN to not be good enough to signal breaking changes. Comparing these three snippets:

• 0.3.0-1234 is out, using a new X to do Y, makes all 0.2.* versions obsolete
• v0.3.0-1234 is out, using a new X to do Y
• build-1234 is out, using a new X to do Y, makes all builds before 1233 obsolete
• don't use build before hash fedcba98, as a new X is now used for Y

makes all v0.2.* versions obsolete is almost unnecessary; most folks already are used to question themselves whether they should upgrade when a new minor is out. This expectation holds even more strongly with such a new and fast paced project as this one (and awesome). I think a mere bump of the build-N number might not do the trick, but it's an acceptable solution, particularly much better than the current hashes.

[Green-Sky]

@longregen I agree with you for the most part, however, since @ggerganov has not yet tagged an actual release, and every "release" so far has been just a "build", going for build-N until we have the first release sounds like a good, current solution.

[Green-Sky]

i am not sure removing the short commit hash is a good idea. sure, having the build number creates a very sortable situation, but it might be funky for branches (can be subject to force pushes, or the same branch name can be reused)

[longregen]

@longregen I agree with you for the most part, however, since @ggerganov has not yet tagged an actual release, and every "release" so far has been just a "build", going for build-N until we have the first release sounds like a good, current solution.

100%. I think this PR is strictly better than the current state. I also agree that the short hash should be included in the build tag for easier lookups.

[DannyDaemonic]

@Green-Sky

i am not sure removing the short commit hash is a good idea. sure, having the build number creates a very sortable situation, but it might be funky for branches (can be subject to force pushes, or the same branch name can be reused)

In addition to making it sortable, I was hoping to simplify it down to something similar to a version number. I hadn't given branches enough thought though. I see why you're the resident ci expert.

It seems to be the branch's malleability that are causing these issues. We could include the short hash only when it isn't master.
For master:
COUNT
And for other branches:
BRANCH-COUNT-HASH

I'm not sure anyone actually uses the hash from the release to look up the code since the release page itself has a hash link that points to exact commit the build comes from. But I suppose if we do want to keep the hash at all times, perhaps a compromise on the simplicity is just, for master:
COUNT-HASH
For other branches:
BRANCH-COUNT-HASH

Thoughts?

[DannyDaemonic]

Still builds after the changes.

[Green-Sky]

hm looking at it, it looks kinda unreadable release-by-build-number-1033-9a13fc4
but mostly bc of the branch name is this case 😄

For master:
COUNT
And for other branches:
BRANCH-COUNT-HASH

@ggerganov I'd like your approval for this, I think this is good.

I'm not sure anyone actually uses the hash from the release to look up the code since the release page itself has a hash link that points to exact commit the build comes from.

its fine, just as i said, this is unlikely to cause issues for master (no forcepushes), and branch releases are rare as is.

[cebtenzzre]

I'm used to seeing the commit number prefixed with 'r', for "revision". On Arch Linux, VCS packages with no tags are versioned as e.g. r1581.2b039da. Their reasoning is as follows:

The revision number delimiter ("r" right before REVISION) is important. This delimiter allows to avoid problems in case if upstream decides to make its first release or uses versions with different number of components. E.g. if at revision "455" upstream decides to release version 0.1 then the revision delimiter preserves version monotonicity - 0.1.r456 > r454. Without the delimiter monotonicity fails - 0.1.456 < 454.

[ggerganov]

hm looking at it, it looks kinda unreadable release-by-build-number-1033-9a13fc4 but mostly bc of the branch name is this case 😄

For master:
COUNT
And for other branches:
BRANCH-COUNT-HASH

@ggerganov I'd like your approval for this, I think this is good.

I'm not sure anyone actually uses the hash from the release to look up the code since the release page itself has a hash link that points to exact commit the build comes from.

its fine, just as i said, this is unlikely to cause issues for master (no forcepushes), and branch releases are rare as is.

Yes - makes sense. I agree with @cebtenzzre that a short prefix on master would be even better

[DannyDaemonic]

A short prefix on master, so something like rNNNN or bNNNN?

I tried to look for any kind of standard but there really isn't one, and as far as I could tell, only Arch Linux uses the "r" prefix. The reasoning is sound though, without a prefix, "1345" will appear newer when sorted against "0.1.0", but "r1345" will appear older when sorted against "v0.1.0".

We could use "b" for build given that we already refer to this number as the "build" in main. I have no strong opinion on the prefix though, let me know and I can change it.

[DannyDaemonic]

I also realized slashes are commonly used in branch names but are not allowed in tag names or file names. So I sub those out as well. (Successful build.)

[Green-Sky]

good catch