Page History

...

git clone https://github.com/${ORG}/${REPO}
cd ${REPO}
git checkout -b ${CURR}-RC origin/${CURR}-RC # ifcheck out the release branch if named differently
mvn release:clean

...

Preparing the release commits

The mvn release:prepare command will update Update all the POM files to set the tags and versions to the release version, then create a commit along with a Git tag. Then change all the versions to the next snapshot. This results in extra commits being automatically added to the local git repositorydevelopment version and change the tag back to HEAD. This will be committed to the current branch as well.

mvn release:prepare -DreleaseVersion=${CURR} -DdevelopmentVersion=${NEXT} -Dtag=${REPO}-${CURR} -DautoVersionSubmodules=true -DpushChanges=false

You may be warned to update project versions. It will give you an option of which versions to update (0: All, 1: Project Dependencies, ....). 1 is the default and is what you should select.

For any dependency it will ask for:

1. the release version, this should be set to the correct released version (i.e. no -SNAPSHOT). In most cases this is the most current released version. 
2. the next development version, this will normally be one minor version above the release version with -SNAPSHOT appended. (i.e. for release version 6.3.0, the development version is 6.4.0-SNAPSHOT)

...

...

You may be warned to update project versions. It will give you an option of which versions to update with options like (0: All, 1: Project Dependencies, ....). 1 (Project Dependencies) is the default and is the correct choice to select.

For any dependency it may ask for:

1. the release version, this should be set to the correct released version (i.e. no -SNAPSHOT). This is the most current released version of that project, not the one you are currently releasing
2. the next development version, this will normally be one minor version above the release version with -SNAPSHOT appended. (i.e. for release version 6.3.0, the development version is 6.4.0-SNAPSHOT)

mvn release:prepare -DreleaseVersion=${CURR} -DdevelopmentVersion=${NEXT} -DautoVersionSubmodules=true -DpushChanges=false -Darguments=-Dgpg.keyname=<your signing key ID>

Anchor
verify local updates verify local updates

Inspect/Verify local updates

git diff

If you have more than one personal key on your GPG keyring, you can specify the correct key by adding

to the above mvn command.

mvn release:prepare -DreleaseVersion=${CURR} -DdevelopmentVersion=${NEXT} -DautoVersionSubmodules=true -DpushChanges=false -Darguments=-Dgpg.keyname=<your signing key ID>

...

git diff HEAD~1

This will show changes from the commit before HEAD to HEAD. It should only show the changes from the release version to the new snapshot version and in at least one place the tag from ${REPO}-${CURR} to HEAD .

i.e. From 6.0.0 → 6.1.0-SNAPSHOT and fcrepo-6.0.0 → HEAD

See https://github.com/fcrepo/fcrepo/commit/8be5b22d9bb0f42b52ff0acf9294fd73fc493b99 for an example

git diff HEAD~2 HEAD~1

This will show changes from the commit 2 before HEAD to the commit before HEADHEAD. It should only show the changes from the old SNAPSHOT release version to the final release new snapshot version and in at least one place the tag from HEAD to ${REPO}-${CURR} to HEAD .

i.e. from From 6.0.0 -SNAPSHOT → 6.01.0-SNAPSHOT and HEAD → fcrepo-6.0.0 → HEAD

See https://github.com/fcrepo/fcrepo/commit/6a13e29dfd5931d3d7d182c841a23763bd8bf7bd8be5b22d9bb0f42b52ff0acf9294fd73fc493b99 for an exampleRemove your local copies of Fedora artifacts to be sure of a clean build, and build the release.

rm -rf ~/.m2/repository/org/fcrepo
git checkout $REPO-$CURR # detached head state i.e. > git checkout fcrepo-6.0.0
mvn clean install

This ensures that all the dependencies can be downloaded from maven to build the artifacts.

...

git push origin --tags

Sonatype Release

Release the build artifacts to the Sonatype repository.

mvn release:perform -DperformRelease -Dgoals=deploy

...

...

If you have more than one personal key on your GPG keyring, you can specify the correct key by adding

to the above mvn command.

mvn release:perform -DperformRelease -Dgoals=deploy -Darguments=-Dgpg.keyname=<your signing key ID>

Troubleshooting

...

...

The above has pushed artifacts to Sonatype in a staging repository. Now you can log in to Sonatype and release them if everything went well

...

Click Staging Repositories in left navigation

...

Search for "fcrepo" in upper right search box (project will not have the repository name in title)

...

git diff HEAD~2 HEAD~1

This will show changes from the commit 2 before HEAD to the commit before HEAD. It should only show the changes from the old SNAPSHOT version to the final release version and in at least one place the tag from HEAD to ${REPO}-${CURR}.

i.e. from 6.0.0-SNAPSHOT → 6.0.0 and HEAD → fcrepo-6.0.0

See https://github.com/fcrepo/fcrepo/commit/6a13e29dfd5931d3d7d182c841a23763bd8bf7bd for an example

Remove your local copies of Fedora artifacts to be sure of a clean build, and build the release.

rm -rf ~/.m2/repository/org/fcrepo
git checkout $REPO-$CURR # detached head state i.e. > git checkout fcrepo-6.0.0
mvn clean install

This ensures that all the dependencies can be downloaded from maven to build the artifacts.

Anchor
push github tags push github tags

Push the changes to Github.

git push origin --tags

Sonatype Release

Release the build artifacts to the Sonatype repository.

mvn release:perform -DperformRelease -Dgoals=deploy

You will be prompted to enter your GPG passphrase. Ensure you have setup your ~/.m2/settings.xml file with the servers defined on Fedora Release Process

mvn release:perform -DperformRelease -Dgoals=deploy -Darguments=-Dgpg.keyname=<your signing key ID>

Troubleshooting

Anchor
publish on sonatype publish on sonatype

Publishing on Sonatype

The above has pushed artifacts to Sonatype in a staging repository. Now you can log in to Sonatype and release them if everything went well

• Go to https://s01.oss.sonatype.org and log in

• Click Staging Repositories in left navigation

• Search for "fcrepo" in upper right search box (project will not have the repository name in title)

• Select the resource and verify that it appears correct.
  Ensure the published date and user appear correct, it should be you.
  Click on the Content tab and check that inside the modules you see artifacts with the correct version numbers.
• Click Close, enter a brief description. Normally something like "Release X.Y.Z" (using the actual version i.e. 6.0.0) is fine.
• Click Refresh, you might have to do this a couple of times until it is in a Closed state.
  
  

git push origin ${CURR}-RC:main

git checkout ${CURR}-RC
git push origin ${CURR}-RC  # i.e. git push origin 6.5.0-RC

Docker Release (fcrepo only)

git checkout fcrepo-${CURR}
mvn clean install -Pfast-build

This assumes you fcrepo and fcrepo-docker repositories are checked out as siblings. 

If you don't have a fcrepo-docker repository checked out then run

git clone https://github.com/fcrepo-exts/fcrepo-docker.git

Change into the fcrepo-docker directory

* 6-tomcat9
* 6.5-tomcat9
* 6.5.0-tomcat9

./build-and-push-to-dockerhub.sh <path to your fcrepo repository>/fcrepo-webapp/target/fcrepo-webapp-${CURR}.war 6-tomcat9 6.5-tomcat9 6.5.0-tomcat9

...

...

You have not pushed your commits to a branch on Github yet (See push changes to github).

If you are NOT working on a past version release, i.e. you are releasing the latest version of the software. Now is a good time to push your main branch onto the repository.

This should always be a fast-forward push and should never require a "force push"

git push origin ${CURR}-RC:main

Now browsing Github you should see two commits with "[maven-release-plugin]" in the label. See examples in Verify local updates

On some repositories (like fcrepo/fcrepo) you are not able to push directly on to main, in this case you should push your release branch up to origin

git checkout ${CURR}-RC
git push origin ${CURR}-RC  # i.e. git push origin 6.5.0-RC

Then open a pull request from the release branch to main, it will have the 2 release related commits. This pull request should NOT be squash merged.

--

If you are working on a past version, see Push Release Branch to Maintenance

Docker Release (fcrepo only)

This should run automatically based on tagged releases to Github, so you can check to see if it appears in https://hub.docker.org/r/fcrepo/fcrepo before proceeding.

You should still have access to your built fcrepo-${CURR}.war file for this.

This assumes you fcrepo and fcrepo-docker repositories are checked out as siblings.

If you don't have a fcrepo-docker repository checked out then run

git clone https://github.com/fcrepo-exts/fcrepo-docker.git

...

cd fcrepo-docker

DOCKER_PASSWORD=<password> DOCKER_USERNAME=<username> ./build-and-push-to-dockerhub.sh <path to your fcrepo repository>/fcrepo-webapp/target/fcrepo-webapp-${CURR}.war latest ${CURRTAGS as defined above}

Make checksums for artifacts

...

Anchor
push rc to maintenance push rc to maintenance

Push Release Branch to Maintenance

...

1. Changing from SNAPSHOT version to release version. Something like [maven-release-plugin] prepare release $REPO-$CURR
2. Changing from release version to next development version. Something like [maven-release-plugin] prepare for next development iteration

If this appears correct, you can push your release branch on to the maintenance branch.

...