...
| 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 |
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 |
| Info |
|---|
The above command arguments are:
|
You may be warned to update project versions. It will give you an option of which versions to update with options like (0: All, 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 (Project Dependencies) is the default and is what you should the correct choice to select.
For any dependency it will may ask for:
- the release version, this should be set to the correct released version (i.e. no -SNAPSHOT). In most cases this This is the most current released version. released version of that project, not the one you are currently releasing
- 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 | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||
|
...
| 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. |
...
| Note |
|---|
This does not push the changes on to any branch. The commits exist on Github but are not associated with a branch, this will come later in case something goes wrong with Sonatype. |
Sonatype Release
Release the build artifacts to the Sonatype repository.
| Code Block |
|---|
mvn release:perform -DperformRelease -Dgoals=deploy |
Release the build artifacts to the Sonatype repository.
...
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 | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||
|
...
| 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"
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
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)
...
(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.
|
This assumes you fcrepo and fcrepo-docker repositories are checked out as siblings.
| Expand |
|---|
/home_directory /fcrepo /fcrepo-docker |
...
| Anchor | ||||
|---|---|---|---|---|
|
...
- Changing from SNAPSHOT version to release version. Something like [maven-release-plugin] prepare release $REPO-$CURR
- 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.
...