I don’t know how to do this directly on GitHub. The "latest version" is determined from the timestamps of your tags, and not from the semantics of their names.
In the past, I solved this problem on my personal projects by removing the problematic old tag:
git tag -d v0.1.0 git push --delete origin v0.1.0
and recreate it with a fake date:
GIT_COMMITTER_DATE="2013-12-31 00:00" git tag -a v0.1.0.1 b217332279 -m "release 0.1.0.1" git push --tags origin master
This is described in the manpage for git-tag :
Regarding back tags
If you imported some changes from another VCS and would like to add tags for major releases of your work, it is useful to be able to specify a date for embedding the tag inside the object; such data in a tag object affects, for example, the ordering of tags in the gitweb interface.
To set the date used in future tag objects, set the GIT_COMMITTER_DATE environment variable (see a later discussion of possible values, the most common form is "YYYY-MM-DD HH: MM").
For example:
$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1
Note that this same man page strongly recommends that you do not use the same tag name:
When re-tagging
What if you flag an invalid commit and you want to re-tag?
If you never pushed anything, just drag it. Use "-f" to replace the old one. And you're done.
But if you pushed things away (or others could just read your repository directly), then others would already see the old tag. In this case, you can do one of two things:
Reasonable thing. Just admit that you are spoiled and use a different name. Others have already seen the same tag name, and if you keep the same name, you may be in a situation where two people have a "version X", but in fact they have different "X". So just name it “X.1” and do it with it.
The crazy thing. You really want to name the new version “X”, even if others have already seen the old one. So just use git tag -f again , as if you hadn't published the old one yet.
However, Git does not (and should not) change tags for users. Therefore, if someone has already received the old tag, do git pull on your tree should not just rewrite the old one.
If someone received a release tag from you, you cannot just change the tag for them by updating your own. This is a big security issue, as people MUST be able to trust their tag names. If you really want to do a crazy thing, you just need to stroke it and tell people that you have soured. You can do this by making a very public announcement:
Ok, I messed up and I popped an earlier version with tag X. I then committed something and returned the fixed tree again as X.
If you received the wrong tag and want a new one, please delete the old one and select the new one by doing:
git tag -d X git fetch origin tag X
to get the updated tag.
You can check which tag you have by doing
git rev-parse X
which should return 0123456789abcdef .. if you have a new version.
Sorry for the inconvenience.
Does this seem a bit complicated? It should be. There is no way that it would be correct to simply “fix” it automatically. People need to know that their tags may have changed.
I would use only the same tag if your project is relatively isolated and you can reliably contact everyone who can use the code.
For more information on deleting deleted tags, see this question .