Versions Compared

Old Version 18

changes.mady.by.user Jared Whiklo

Saved on

compared with

New Version Current

changes.mady.by.user Jared Whiklo

Saved on

Key

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

...

Code Block
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


Warning

If mvn release:clean fails, you may need to revert the RC commit

...

with git revert HEAD.  If the parent snapshot is not available, build an old version of fcrepo to populate it locally.

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.

Code Block
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)
 Info
The above command arguments are:
  • -DreleaseVersion - this is the numeric version you are releasing, i.e. 6.1.0, 5.6.1, etc
  • -DdevelopmentVersion - this is the next snapshot version. It should be one minor version above the release version and it should always end with -SNAPSHOT. i.e. 6.2.0-SNAPSHOT, 5.7.0-SNAPSHOT
  • -Dtag - this is the git release tag which will point to the release commit. It is <repository name>-<release version>. i.e. fcrepo-camel-toolbox-6.1.0, fcrepo-import-export-6.2.0, fcrepo-6.5.0
  • -DautoVersionSubmodules=true - because Fedora is made up of a bunch of modules, this ensure they also get processed.
  • -DpushChanges=false - this ensure changes are not automatically pushed to Github.
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)

 Note
titleYour GPG passphrase may not be masked in terminal.

 Expand
titleIf you have more than one GPG key? Click here to expand...
If you have more than one personal key on your GPG keyring, you can specify the correct key by adding
-Darguments=-Dgpg.keyname=<Your Key ID>
to the above 
 Note
titleYour GPG passphrase may not be masked in terminal.
 Expand
titleIf you have more than one GPG key? Click here to expand...
If you have more than one personal key on your GPG keyring, you can specify the correct key by adding
-Darguments=-Dgpg.keyname=<Your Key ID>
to the above mvn command.
 Code Block
languagebash
titlefor example
mvn release:prepare -DreleaseVersion=${CURR} -DdevelopmentVersion=${NEXT} -DautoVersionSubmodules=true -DpushChanges=false -Darguments=-Dgpg.keyname=<your signing key ID>


...
 Info
The maven release task relies on the tag existing in the repository, make sure there is not a branch with the same name or it will be used instead and cause errors.
...
 Code Block
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
 Note
titleYour GPG passphrase may not be masked in terminal.

 Expand
titleIf you have more than one GPG key? Click here to expand...
If you have more than one personal key on your GPG keyring, you can specify the correct key by adding
-Darguments=-Dgpg.keyname=<Your Key ID>
to the above mvn command.
 Code Block
languagebash
titlefor example
mvn release:perform -DperformRelease -Dgoals=deploy -Darguments=-Dgpg.keyname=<your signing key ID>


...
 Tip
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"
 Code Block
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
 Code Block
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.
...
Maintenance

Docker Release (fcrepo only)
 Info
You should still have your built Fedora webapp war file. (i.e. fedora-webapp-${CURR}.war)
Checkout the tagged version of Fedora and build it.
 Code Block
git checkout fcrepo-${CURR}
mvn clean install -Pfast-build
This assumes you fcrepo and fcrepo-docker repositories are checked out as siblings. 
 Expand
/home_directory
     /fcrepo
    /fcrepo-docker
...
 Info
We want to release with 3 tags for each release.
  • MAJOR-tomcat9
  • MAJOR.MINOR-tomcat9
  • MAJOR.MINOR.PATCH-tomcat9

For  
 Code Block
titleFor example 
- for version 
 6.5.0

* 6-tomcat9
* 6.5-tomcat9
* 6.5.0-tomcat9
These tags are provided at the end of command below separated by spaces
 Code Block
titleFor example - for version 6.5.0
./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

...
 Code Block
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.
...