-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
v1.67.0 tag has 1.68.0 version number #11550
Comments
There are already published artifacts that depend on v1.68.0 so I don't think unpublishing is an option. Unless you really need to sync up with some other 1.67.x releases - I notice grpc-go is also at 1.67.0 - you might consider skipping 1.67.x and continuing at 1.68.x. Even if you publish a v1.67.1 release, v1.68.0 is still going to appear as a newer version and is likely to get picked up in preference by dependency updates for dependent projects. |
That'd be a reason to unpublish. And anyone picking up a new version before there are release notes... I know there's lots of tooling that encourages this, but... In any case, I think we can't unpublish. So the main problem is if we make v1.67.x patch releases people on the fake 1.68.0 won't get it from automated tooling. Version numbers are synchronized. |
You could just go directly to 1.68.X for the next releases? |
Hey team, I am planning to upgrade to the latest version. |
@nyukhalov |
I created a v1.68.0 tag that was identical to v1.67.0 tag, then I deleted the v1.67.0 tag. I've created release notes for v1.68.0 that explain it was a mistake. This is only going to fully resolve when we get to v1.68 for real in a few weeks, but we've done what we can for now. |
b570d07
Note that the PR was fine. #11536
What probably happened was a mess-up when creating the release commits. Then deleting them and starting over, but not deleting the tag. And then when creating the new commits failing to create the tag (ignoring the error message).
We'll need to create a 1.67.1 since the 1.67.0 tag is "spent" (never re-create a tag after it has been pushed to the main repo; you can potentially delete a tag, but never create something new in its place).
And then for v1.68.x we'll need to skip over 1.68.0. That may turn out to be pretty annoying. We can check whether we can revoke v1.68.0, but even if we can, we need to skip over the version number when releasing v1.68.x.
@kannanjgithub
The text was updated successfully, but these errors were encountered: