Versions Compared

Old Version 116

changes.mady.by.user Philip Smart

Saved on

compared with

New Version 117

changes.mady.by.user Philip Smart

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Ensure you are using the correct Java version e.g. Amazon Corretto 17.

    1. 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.

  2. 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

  3. Check that a non-snapshot version of maven-dist-enforcer and maven-dist-enforcer-data are used.

  4. Check the .check-m2 file is in the projects distribution project.

  5. Check the project builds, all the tests pass, and the artifacts are produced correctly (signed in their target directories):

    1. Code Block
      mvn -Dmaven.repo.local=$REPO -Prelease,sign clean verify

    2. 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.

      1. mvn -Dmaven.repo.local=$REPO -Prelease,sign clean install then vi target/m2SignatureReport.txt . This is automatically checked on deploy, so is not required.

  6. 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

  7. 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
    languagebash
    # 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

  8. 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

  9. Edit the POM and update any first-party project dependencies to the next SNAPSHOT increment. Avoid updating third-party dependencies unless necessary.

    Code Block
    vi pom.xml
# Updated project dependencies to next SNAPSHOT increment.

  10. 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

  11. 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

  12. 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

  13. 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.

  14. Mark the version as released in Jira.

...