Hi, I first tested FileVault, which succeeded w/o problems. Then I tested the plugin, which failed because of the missing 3.4.6. Then I run `mvn clean install` in the `target/jackrabbit-filevault-3.4.6/svn/jackrabbit-filevault-3.4.6` directory. After that, the check release succeeded for the plugin as well.
Regards, Toby > On 31 Jul 2020, at 02:35, Julian Reschke <[email protected]> wrote: > > 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
