Verifying a Release

The release process consists of:

  • the release manager cutting the release

  • members of the Apache Causeway 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 Causeway PMC and anyone else who wishes) is expected to do before casting their vote in order to verify a release.

Background

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 Causeway 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 DEPENDENCIES file 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.

Prerequisites

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

  • JDK 17

    v2 is for the most part compatible with Java 11 and almost all of the modules target Java 11. The one exception is GraphQL viewer’s test modules, which require Java 17.

  • Apache Maven (mvn) 3.9.6+

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=3.2.0
RC=RC1
NEXUSREPONUM=11xx

curl https://downloads.apache.org/causeway/KEYS > /tmp/KEYS
gpg --import /tmp/KEYS

rm -rf causeway-$VERSION

curl -O -L https://raw.githubusercontent.com/apache/causeway/release-$VERSION-$RC/scripts/verify-causeway-release.sh

chmod +x ./verify-causeway-release.sh
./verify-causeway-release.sh $NEXUSREPONUM $VERSION $RC

The verify-causeway-release.sh script performs these steps:

  • downloads artifacts (.zip file and .asc file) from the staging repository hosted on https://repository.apache.org.

  • verifies that the .asc signature is correct

    in other words, to confirm that the release was created by an Apache Causeway committer

  • builds the framework code from source

  • downloads and builds the helloworld starter app (for the jdo branch and also for the jpa branch)

  • ditto for the simpleapp starter app

Assuming this completes successfully, you can then test the starter applications:

  • Test out helloworld (jdo) using:

    pushd causeway-app-helloworld-jdo
mvn spring-boot:run
popd

  • Test out helloworld (jpa) using:

    pushd causeway-app-helloworld-jpa
mvn spring-boot:run
popd

  • Test out simpleapp (jdo) using:

    pushd causeway-app-simpleapp-jdo
mvn -pl webapp spring-boot:run
popd

  • Test out simpleapp (jpa) using:

    pushd causeway-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://causeway.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.

Creadur’s remaining tools - Tentacles and Whisker - are to support the verification process.

For example, Tentacles generates a report called archives.html. This lists all of the top-level binaires, their LICENSE and NOTICE files and any LICENSE and 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)'

Casting a Vote

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.