...
Ensure you are using the correct Java version e.g. Amazon Corretto 17.
If you are building the IdP, make sure you set MAVEN_HOME to the bin directory of your maven installation so the distribution-dependency-test runs correctly in idp-installer.
Ensure that your working copy is in sync with the project repository (i.e., pull down any updates and commit any local changes). It can be useful to do this from scratch from a temporary folder, possibly inside a clean docker container. For example, into the temp directory, using a fresh maven repo location.
Code Block # incase you get issues connecting to the GPG agent. export GPG_TTY=$(tty) # somewhere to store a fresh maven repo. If you want to preserve the transient release repo for archiving, etc, # use a permanent location for REPO, with the version in the name. export REPO=/tmp/repo cd /tmp git clone git@git.shibboleth.net:<project> cd <project> git checkout main
Check that a non-snapshot version of maven-dist-enforcer and maven-dist-enforcer-data are used.
Check the
.check-m2
file is in the projects distribution project.Check the project builds, all the tests pass, and the artifacts are produced correctly (signed in their target directories):
Code Block mvn -Dmaven.repo.local=$REPO -Prelease,sign clean verify
OPTIONALLY: If you want to manually inspect the signature report on the contents of the populated m2 directory, you need to use the
install
phase e.g.mvn -Dmaven.repo.local=$REPO -Prelease,sign clean install
thenvi target/m2SignatureReport.txt
. This is automatically checked ondeploy
, so is not required.
Set the project version number in the POM to the release version number using the command below. Also, ensure you update versions of any dependencies on our own projects that should be shipped with the release.
Code Block mvn -Dmaven.repo.local=$REPO -DgenerateBackupPoms=false -DnewVersion=4.Y.Z versions:set
Once satisfied, tag the release using a name equal to the version number of the release (e.g., 4.1.4 etc.) and ensure the POM at the tip of the branch being released NEVER contains a non-SNAPSHOT version number.
Code Block language bash # Be sure there are SNAPSHOTs in the right places. So from the root directory of the project: find . -name 'pom.xml' -exec grep SNAPSHOT {} \; # Check status git status # Confirm changes manually git diff # Assume working copy is on branch 'main', with ONLY tag-specific changes pending # (e.g. non-SNAPSHOT version) # Add the changes git add -A # Confirm changes have been added git status # Commit the changes to be tagged to the HEAD of the branch git commit -m "Update files to be tagged for release" # Create a signed, annotated tag from HEAD git tag -s -m "Tag 4.Y.Z release" 4.Y.Z
Once tagged, set the project version number in the POM to the next SNAPSHOT increment.
Code Block # Edit pom.xml to update the version to X.Y.Z+1-SNAPSHOT (in the example, 4.1.5-SNAPSHOT). mvn -Dmaven.repo.local=$REPO versions:set -DnewVersion=4.Y.Z+1-SNAPSHOT -DgenerateBackupPoms=false
Add and commit the changes you made, and then push the tag.
Code Block # Commit the pom.xml change. git add -A git commit -m "Bump version after release" # Push the new commits. git push # Do not push the tag. Signature checking is more restrictive for non SNAPSHOT builds
Checkout or export the tag to build the final release:
Code Block git checkout 4.Y.Z mvn -Dmaven.repo.local=$REPO -DskipTests -Prelease,sign clean deploy
After the build has been completed push the tag
Code Block # Push the new tag (no easy backout when the tag is pushed!) git push origin 4.Y.Z
At this stage, DO NOT make any changes to fix errors without increasing the version again. This commits you to a release and you cannot go back.
Mark the version as released in Jira.
git push origin 4.Y.Z
At this stage, DO NOT make any changes to fix errors without increasing the version again. This commits you to a release and you cannot go back.
Mark the version as released in Jira.
Post Product Release
After releasing all projects, manually edit their POM files and update any first-party project dependencies to their next SNAPSHOT increment to unlock them..
Code Block |
---|
cd /tmp
git clone git@git.shibboleth.net:<project>
cd <project>
git checkout main
vi pom.xml
# Updated project dependencies to next SNAPSHOT increment.
git add -A
git commit -m "Unlock first-party dependencies" |
Javadoc Release Process
Note |
---|
So far as I know, this process does not require a separate repo, but it does assume you have variables defined for $MAVEN and $REPO to run, and as usual you have to be logged into the server for the Nexus deploy step to work. Additionally, it will assume your SSH user name is $USER (from your shell) but may be overridden by setting $USERNAME. |
...
Windows Installer
This is described separately forWiX3 and Wix4.
Releasing the “enforcer” plugins.
...