Verifying a Release
The release process consists of:
the release manager cutting the release
members of the Apache Isis PMC verifying and voting on the release (documented below)
the release manager performing post-release tasks, for either a successful or an unsuccessful vote.
This section describes some guidance on what a voter (members of the Apache Isis PMC and anyone else who wishes) is expected to do before casting their vote in order to verify a release.
Whenever a release manager announces a vote on a release (as per the release process) on the dev mailing list, it is the responsibility of the project’s PMC to cast their vote on the release. Anyone else can also vote, but only members of the Apache Isis PMC’s vote are binding.
Per this ASF documentation, the legal requirements for an ASF release are:
a source zip file + corresponding signature (signed by the release manager, which is in the ASF web of trust and in our KEYS file)
all source files have the Apache license (this is ensured by the running of the rat plugin prior to release; you could run it on the unzipped source)
all dependencies are appropriately licensed; see the
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. That said, you might also want to verify the release by pulling the binaries from the Maven staging repository. Details of how to do this are also documented below.
You will also require the following commands/tools:
bash- to run shell script
curl- to download the ZIP and ASC files
gpg- to verify signatures
unzip- to unzip the ZIP files
Apache Maven (
Verifying source artifacts
The easiest way to verify the source artifacts is to use a script that automates the steps. Run these commands, with the environment variables set correctly. (The full details should also be in the VOTE email):
VERSION=2.0.0-M9 RC=RC1 NEXUSREPONUM=11xx curl https://downloads.apache.org/isis/KEYS > /tmp/KEYS gpg --import /tmp/KEYS rm -rf isis-$VERSION curl -O -L https://raw.githubusercontent.com/apache/isis/release-$VERSION-$RC/scripts/verify-isis-release.sh chmod +x ./verify-isis-release.sh ./verify-isis-release.sh $NEXUSREPONUM $VERSION $RC
verify-isis-release.sh script performs these steps:
downloads artifacts (
.ascfile) from the staging repository hosted on https://repository.apache.org.
verifies that the
.ascsignature is correct
in other words, to confirm that the release was created by an Apache Isis committer
builds the framework code from source
downloads and builds the helloworld starter app (for the
jdobranch and also for the
ditto for the simpleapp starter app
Assuming this completes successfully, you can then test the starter applications:
Test out helloworld (jdo) using:
pushd isis-app-helloworld-jdo mvn spring-boot:run popd
Test out helloworld (jpa) using:
pushd isis-app-helloworld-jpa mvn spring-boot:run popd
Test out simpleapp (jdo) using:
pushd isis-app-simpleapp-jdo mvn -pl webapp spring-boot:run popd
Test out simpleapp (jpa) using:
pushd isis-app-simpleapp-jpa mvn -pl webapp spring-boot:run popd
You can if you wish perform some additional optional checks, listed below. And/or, you can go ahead and cast your vote.
(Optional) Verify Website
The next version of the website can be found at https://isis.staged.apache.org.
(Optional) Creadur Tools
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 release process.
For example, Tentacles generates a report called
This lists all of the top-level binaires, their
NOTICE files and any
NOTICE files of any binaries they may contain.
Validation of the output at this point is all still manual. Things to check include:
any binaries that contain no LICENSE and NOTICE files
any binaries that contain more than one LICENSE or NOTICE file
In this report, each binary will have three links listed after its name '(licenses, notices, contents)'