Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

git describe returns incorrect version #5868

Closed
ingvagabund opened this issue Mar 24, 2015 · 8 comments
Closed

git describe returns incorrect version #5868

ingvagabund opened this issue Mar 24, 2015 · 8 comments

Comments

@ingvagabund
Copy link
Contributor

The latest release is v0.13.2, git describe returns v0.12.0-1145-ged68c8e. How does the master branch relates to the latest release? Is "git describe"'s output intended to be v0.12.0 or is it a bug? This is not the first time inconsistency. Thanks.

@roberthbailey
Copy link
Member

@zmerlynn Zach tagged that build so maybe he can help here?

@fabioy
Copy link
Contributor

fabioy commented Mar 24, 2015

I believe Jeff has a PR for this already (PR #5817).

Thanks.

@zmerlynn
Copy link
Member

The problem here is that despite actually being merged into master, 8d8b9b9 is not reachable from head because of contorted pull gymnastics. You can actually do a git describe on c04ceec which introduces it, and you'll see:

$ git describe c04ceec27f72350b0964e04096ae14c18bee865f
v0.12.0-792-gc04ceec

... which is bad news bears. That's because those two commits, 7fbf52a and 8d8b9b9, once they hit master, really don't exist in their present form, so the tag actually only applies to the branch commit, as pointed out both here and in #5817.

@zmerlynn
Copy link
Member

This is all coming about because we changed procedure slightly. The release was based on a good Jenkins run, tagged off there, and then we inject the release number change back into the master branch. I think we need to tag master with something else.

For now, I'm going to tag the branch point as v0.13.0-dev, which may break other things, but actually matches the version stamp we put in pkg/version/base.go

@eparis
Copy link
Member

eparis commented Mar 24, 2015

@jbeda has fixed this problem before. how do we stop it from happening?

@zmerlynn
Copy link
Member

We have better scripts. I'm looking at it.

@zmerlynn
Copy link
Member

This actually came about because we changed to a better procedure that allows cranking the release pretty quickly off a clean Jenkins run, rather than just twiddling thumbs waiting on e2e.

@zmerlynn
Copy link
Member

I pushed a v0.13.1-dev tag because @brendanburns v0.13.0 chain was so uniquely messed up that I couldn't reconstruct a useful tag from it.

Closing this.

(BTW, we've never returned the minor version correctly. We typically return the major version, but 0.13.1 was, erm, special and a complete re-release.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants