I’d never really noticed it before, but today I saw that the Bitcoin Core release is at version 29.1, but the tags go up to 30, and there’s even a 29.2 after 30. Can someone explain what’s going on here?
A tag is a unique label to a commit on the git side of things.
A release is native functionality in GitHub, where you take a tag and you add further information to it, like release text/notes, a title, and optionally, binaries.
So first you tag in git, with git tag, then you push that tag to GitHub, then you write the release on GitHub (or via API). Also see the release process doc for Bitcoin Core specifically.
There can also be backport releases where a patch gets applied to an earlier supported branch which results in version numbers that appear out of sequence relative to work on the main branch. For example a 29.2 release might carry important security fixes for people still running on the 29.x line even while development tags march forward toward 30.x and beyond...
A
tagis a unique label to a commit on thegitside of things.A
releaseis native functionality inGitHub, where you take atagand you add further information to it, like release text/notes, a title, and optionally, binaries.So first you tag in
git, withgit tag, then you push that tag toGitHub, then you write the release on GitHub (or via API). Also see the release process doc for Bitcoin Core specifically.So basically, can I say a tag is just a release without the makeup, but the binary files are the same?
Yes. The guix process builds binaries from
taganyway.There can also be backport releases where a patch gets applied to an earlier supported branch which results in version numbers that appear out of sequence relative to work on the main branch. For example a 29.2 release might carry important security fixes for people still running on the 29.x line even while development tags march forward toward 30.x and beyond...