Am 30.07.2020 um 18:36 schrieb Konrad Windszus:
On 30. Jul 2020, at 16:35, Julian Reschke <[email protected]
<mailto:[email protected]>> wrote:
So, when taking the vote instructions literally, I should veto
the release...
The vote instructions in my email do not say anything about failed
execution of check-release.sh, but vote however you want to.
I already gave updated instructions that should hopefully fix the issue
(I haven't heard back from you whether that fixed the issue)
If you still veto the release due to that that is up to you.
I didn't veto it, I just did not vote *for* it because I didn't have
time to workaround the issue (yet).
Toby: as you voted +1 already, how did *you* verify the second release?
Did you have 3.4.6 installed localled?
IIUC, I would have to git clone vault at 3.4.6, and run "mvn install",
and then would be able to run the check for the plugin?
But we should probably all think about what would be a good reason to
veto a release.
Missed instructions on how to check the release are IMHO not a very
convincing reasons....
Back to the topic: I would recommend to adjust the check-release.sh that
also the staging repo is transparently added as new remote repo for the
Maven execution.
WDYT?
Konrad
That would fix the immediate issue (I assume), but is somehow risky
because then it get's harder to understand what actually is checked.
I get that in this case we have a combined vote for these two releases,
and that they are only released in tandem or not at all.
But what if one of these had a dependency on something that happens to
be in the staging repo right now, but which is not part of the vote?
It might be better if check-release actually installed the artefact
locally. I already tried that by changing the MVN_ARGS in the script,
but couldn't get that working.
Best regards, Julian
