Danny>Actually I do not know how to config the authentication for the eclipse plugin that the Gradle task uses, is there any doc/instructions that I can reference ?
I have never tried (I always release via command line like ./gradlew prepareVote -Prc=2 -Pasf <-- it is just enough), however, the following seems relevant: https://discuss.gradle.org/t/eclipse-buildship-global-gradle-properties-not-read/18941 In other words: it should read .gradle/gradle.properties in your home directory or in the directory that you configure in Eclipse (if you configure an override there) The properties are asfNexusUsername=test asfNexusPassword=test asfGitSourceUsername=test asfGitSourcePassword=test asfSvnUsername=test asfSvnPassword=test signing.gnupg.keyName=289023DE2663BD17 # The following two options would use native gpg executable for signing (== with gpg-agent support) useGpgCmd=true signing.gnupg.useLegacyGpg=true # The following would configure Java's PGP signing implementation signing.keyId=289023DE2663BD17 signing.password=qwerty signing.secretKeyRingFile=.../.gnupg/secring.gpg Danny>There is no rc tag in the Calcite repository Because we have never released with Gradle yet. -rc tags could be deleted after the vote passes. However, a mere presence of -rc tags makes it obvious there's a vote pending, and it avoids confusion whether calcite-1.22.0 tag is the release tag or not. $ git ls-remote origin | grep 1.22.0 e397e47b0752c0647590097584903a9561a646eb refs/tags/calcite-1.22.0 The current refs/tags/calcite-1.22.0 does look like a release tag, however, it is not an official release yet. Danny>we did has a tag for each release with pattern Calcite-1.22.0, so I would not follow you in this part, the original work flow is ok for me. Note: the final release tag name should have rel/ prefix. This was a decision of the Board 3 years ago: https://lists.apache.org/thread.html/6d9bc4a603214552804f4c4f8e3c7f0ae260556019b1414caf6f5825%401452448804%40%3Cprivate.calcite.apache.org%3E Note: rel/... tags are immutable, and it would be extremely hard to delete them. So rel/... namespace should not be used for release candidate tags. Here's the relevant quote from 6d9bc4a60321... email: David>Second, we've changed the 'protected' portions of git to primarily David>focus on refs/tags/rel - thus any tags under rel, will have their David>entire commit history. This provides the provenance that the ASF needs David>for releases, while still giving projects the ability to mold their David>repository in the way they see fit. David>Thus when a release vote is successful - part of the release process David>should become tagging the voted upon commit SHA under rel/ to make it David>indelible. ('# git tag rel/v15.4.2 ' or something similar.) Vladimir
