Whenever a committer announces a vote on a release on the dev mailing list, it is the responsibility of the project's PMC to cast their vote on the release. Any other ASF member may also vote.
This page provides some guidance on what a voter is expected to verify before casting their vote. There is a script available but please read this page before executing that.
Per this ASF documentation, the legal requirements for an ASF release are:
DEPENDENCIESfile which is automatically generated from the POMs plus the supplemental-models.xml file
Note that the binaries are not an ASF release, they merely exist on the Maven central repo as a convenience.
Download both the ZIP and .ASC files from the location specified in the voting email. To verify that the signature is correct, use:
gpg --verify isis-x.y.z.zip.asc isis-x.y.z.zip
Assuming the ZIP file verifies, it should be unpacked, and then the artifact built from source.
First, delete all Isis artifacts from your local Maven repo:
rm -rf ~/.m2/repository/org/apache/isis
The build process depends on whether the artifact is of Isis core or of one of its components:
mvn clean install -o
Confirm that the versions of the Isis artifacts now cached in your local repository are correct.
mvn clean install
Confirm that the versions of the Isis artifacts now cached in your local repository are correct (both those pulled down from Maven central repo, as well as those of the component built locally).
The above steps are the bare minimum you should perform before casting a vote. Ideally, you should also run an Isis application (eg one of the examples) against the new code (either against a new version of core, or configured to use the new version of the component).
Optionally, you can verify the binary releases (in the Maven staging repository). For this it is necessary to download each artifact from Nexus and its corresponding .ASC file. Since there are many such artifacts, just verify one or two at random.
The Apache Creadur project exists to provide a set of tools to ensure compliance with Apache's licensing standards. The main release auditing tool, Apache RAT, is used in the preparation of the release (as documented here). Creadur's remaining tools are to support the verification process.
At the time of writing, these additional tools are quite young and haven't been formally released; so to use them will take a little bit of work. See here for more details.
When you have made the above checks (and any other checks you think may be relevant), cast your vote by replying to the email thread on the mailing list. If you are casting
-1, please provide details of the problem(s) you have found.
All edits are reviewed before going live, so feel free to do much more than fix typos or links. If you see a page that could benefit from an entire rewrite, we'd be thrilled to review it. Don't be surprised if we like it so much we ask you for help with other pages :)NOTICE: unless indicated otherwise on the pages in question, all editable content available from apache.org is presumed to be licensed under the Apache License (AL) version 2.0 and hence all submissions to apache.org treated as formal Contributions under the license terms.