The latest master commits are on the 0.4.0 branch, while 0.11.0 is the latest version

[yurivict]

git describe --tags shows that the latest commits in master have the tag:
v0.4.0-pre2-802-g4dff795ca

But the Releases tab shows that 0.11.0 is the latest version.

[ghost]

git describe --tags only shows tags for the current branch. Per the docs, we create a new branch for the release. For this reason the tag on master isn't up to date. What particular use-case do you need this for?

[yurivict]

What particular use-case do you need this for?

In order to use the latest commit after the latest release git describe --tags is used. Normally all projects have master on the latest release, but you don't.

[ghost]

Yep, that's annoying and I apologize for that. I'll let @coryan chime in on what to do about that.

Meanwhile, you can workaround it by getting similar behavior to git describe --tags:

LATEST_TAG=$(git describe --tags $(git rev-list --tags --max-count=1))
COMMITS_SINCE=$(git rev-list --count $LATEST_TAG..HEAD)
HEAD_SHA=$(git rev-parse --short HEAD)
RESULT="$LATEST_TAG-$COMMITS_SINCE-$HEAD_SHA"
echo $RESULT

[coryan]

We should change the way we cut releases. What follows is just to help me (or my colleagues) when we do decide to fix this stuff:

• We create the vX.Y.0 tag on the release branch because there is at least one commit on the branch.
• This commit is just there to setup a flag (GOOGLE_CLOUD_CPP_IS_RELEASE). We could change that to be based on whether the .git directory exists (which would set to on more than just releases, so name it GOOGLE_CLOUD_CPP_NOT_DEVELOPMENT or something).
• We could achieve a similar effect (not exactly the same, but close enough), using .gitattributes and ignoring a flag file during export. Or we could create our own tarballs as part of the release process.

[coryan]

FWIW, I think this was fixed by #2963. Though naturally only future tags will be in master.