release 1.0.0

[jyane]

grpc-java 1.10.0 is now released. So we can publish this tool.

I think the plans are:

1. Verify that this tool could work with grpc-java 1.10.0
2. Bump version to 1.0.0 from 1.0-SNAPSHOT (Create a PR)
3. Push a v1.0.0 tag to GitHub (Push directly)
4. Publish to maven central
5. Bump version to 1.1.0-SNAPSHOT for starting the 1.1.0-SNAPSHOT development iteration (Create a PR)

Could I be granted the permission? https://issues.sonatype.org/browse/OSSRH-14103
If it could not, please release the 1.0.0 by another team member.

@ericgribkoff, @ejona86 What do you think?

[ericgribkoff]

@jyane This sounds good. I will have to handle publishing to maven central - I don't think we can grant access to the io.grpc OSSRH project outside of the gRPC team.

Given that I'll handle step 4, would you like me to do the other steps of the release process or would you prefer to handle those yourself? Either way is fine with me. Thanks!

[jyane]

@ericgribkoff Thanks! Please handle step 4.
I will do the 2 and 3 then notify you when step 3 be done (tag push will be direct).
I think this command mvn clean deploy -Dpublic-release=true would work for the publish.

[ericgribkoff]

@jyane Sorry for the last minute change, but I was discussing this with @ejona86 and it might be a little confusing for users if we publish directly into the io.grpc group id, since all of the other gRPC Java artifacts (e.g., core, netty, etc) are on the same version whereas grpc-java-api-checker's version number is and will be independent (that said, Guava does put their beta checker tool directly in the com.google.guava package)

What do you think about moving this into its own subgroup? Maybe io.grpc.tools or io.grpc.annotations?

[jyane]

@ericgribkoff SGTM. I will remove that tag and create a PR for changing their packages.
io.grpc.tools or io.grpc.annotations, either is fine.

[jyane]

I've removed the tag.

[ericgribkoff]

We've reached consensus on io.grpc.tools :-) Thanks for your flexibility on this! I'll be ready to deploy the package once you update the name.

[ericgribkoff]

So, the good news first: the package is released! The bad news: I got tripped up by the deleted tag and ended up pushing the tag when it pointed at e98e7f1, with the io.grpc group. And I didn't realize until it was too late that the maven deploy command does not just push the artifacts into staging but does the complete release, so when I noticed my mistake with the tag it was too late to correct it.

The well-its-not-too-bad outcome: Functionally the released tag works just fine. We were just slightly in favor of io.grpc.tools over io.grpc anyways, and my mistake has now forced the io.grpc package upon us.

Sorry for yet more cleanup. I just sent you PR #10 reverting the io.grpc.tools name change.

Apparently it can be problematic deleting tags in general (see https://www.kernel.org/pub/software/scm/git/docs/git-tag.html#_on_re_tagging), which I was not aware of until now but will remember moving forward :) As we now have the v1.0.0 tag that (due to my error) is not pointing to the actual release commit, we could delete and recreate it again, but I think we should just leave it as-is and create a new tag v1.0.0.release or some such and point it to e98e7f1

[ejona86]

If the tag is misleading (say, because it points to the wrong commit), then it can be fine to delete it (and never re-create it). But you shouldn't overwrite a tag with a new value.

For example, the in the 1.6.0 release process the tag was pointing at the wrong commit. We deleted the tag and created 1.6.1 for the release instead.

[jyane]

First, thank you for your work @ericgribkoff.

I just want to make sure what happened and what we should do.

1. I have created a tag it points at e98e7f1
2. I have deleted 1.'s tag
3. I have reverted release commits
4. I have changed package names to io.grpc.tools
5. I have created a tag it points at 9539541

I think ericgribkoff has already cloned or fetched 1.'s tag to his local git repository, so re-creating tag (that means 2., 3., 4. and 5.) does not work correctly. And then, this tool was released as a io.grpc.
Once the tool was released, we should use the same group id on maven central, so ericgribkoff creates #10.

@ejona86 Your comment means when releasing artifacts at wrong tag? In this case, the previous v1.0.0 tag (that means 1.) works and it was released, so releasing v1.0.1 is not needed? Is my understanding correct? Or should release v1.0.1 as a io.grpc.tools?

[ericgribkoff]

Yes, steps 1-5 are what happened. Since I cannot undo the release of the tool to maven central under the io.grpc package, it's probably less confusing moving forward to keep that as the permanent package name.

So v1.0.1 will stay under io.grpc when we release it, but I don't think we need to release immediately just because of the tagging issue - I'll let @ejona86 weigh in on that, as it may be more important than I realize to have a tag exactly matching the latest maven central version.

We should definitely delete the current v1.0.0 tag here (since it points to something that is not a release), but since I've already messed up the exact 1-1 match between the tag name and the release for v1.0.0, I think it might be enough to have a new tag (something obviously not exactly the same as the release number, e.g., v1.0.0-released) that points to commit e98e7f1. But again I'm not fully sure of the convention here, so if necessary we can skip this v1.0.0-released tag and just push a new release v1.0.1 with a new tag.

[jyane]

OK, I got. Second, I'm sorry for my harmful git use.
I'm also waiting for @ejona86 's comment.