...
| Code Block |
|---|
git clone https://github.com/${ORG}/${REPO}
cd ${REPO}
git checkout -b ${CURR}-RC origin/${CURR}-RC # if the release branch if named differently
mvn release:clean |
| Warning |
|---|
If 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} -DautoVersionSubmodules=trueDtag=${REPO}-${CURR} -DautoVersionSubmodules=true -DpushChanges=false |
| 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 0 - 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 (0: All, 1: Project Dependencies, ....). 1 is the default and is what you should select.
...
| Note |
|---|
| title | Your GPG passphrase may not be masked in terminal. |
|---|
|
| Expand |
|---|
| title | If 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 |
|---|
| language | bash |
|---|
| title | for example |
|---|
| mvn release:prepare -DreleaseVersion=${CURR} -DdevelopmentVersion=${NEXT} -DautoVersionSubmodules=true -DpushChanges=false -Darguments=-Dgpg.keyname=<your signing key ID> |
|
|
...
| Note |
|---|
| title | Your GPG passphrase may not be masked in terminal. |
|---|
|
| Expand |
|---|
| title | If 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 |
|---|
| language | bash |
|---|
| title | for example |
|---|
| mvn release:perform -DperformRelease -Dgoals=deploy -Darguments=-Dgpg.keyname=<your signing key ID> |
|
|
...
| Anchor |
|---|
| push rc to maintenance |
|---|
| push rc to maintenance |
|---|
|
Push Release Branch to Maintenance
...
- 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.
...