...
Resolve dependencies and set main versions to $CURR
and dev versions to $NEXT
Code Block | ||
---|---|---|
#For vivo languages, vitro languages, jenatools, and orcid-api-client
mvn release:prepare -DreleaseVersion=$CURR -DdevelopmentVersion=$NEXT -DautoVersionSubmodules=true -DpushChanges=false | ||
Note |
Expand | ||
---|---|---|
| ||
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. |
Inspect/Verify local updates:
Code Block |
---|
git diff HEAD~1
git diff HEAD~2 HEAD~1 |
These diffs should only contain changes of version numbers (from ${CURR}-SNAPSHOT to $CURR or $CURR to $NEXT) or occasionally HEAD to the current tag name ($REPO-$CURR)
Remove your local copies of VIVO artifacts to be sure of a clean build, and build the release.
Code Block |
---|
rm -rf ~/.m2/repository/org/vivoweb
git checkout $REPO-$CURR # detached head state
mvn clean install |
Warning |
---|
Up until this point, all of the changes made are strictly in your local repository and working directory. From this point on, the changes you make will be visible to the world and in some cases difficult to back-out of. |
Push the changes to Github.
Code Block |
---|
git push origin --tags # mvn task relies on the tag, make sure it does not collide with a branch name |
Go to
https://github.com/vivo-project/$REPO/releases/
- Click "Draft a new release", and update title to "Release $CURR"
- Attach appropriate artifacts
- Attach artifact MD5 files (e.g. artifact = jena2tools-1.2.0.jar, MD5 = jenatools-1.2.0.jar.md5)
If appropriate, attach binaries and checksums that have been published to Maven Central- Click Publish Release
Sonatype Release
Release the build artifacts to the Sonatype repository.
Code Block |
---|
mvn release:perform -DperformRelease -Dgoals=deploy |
...
As before, your GPG passphrase may not be masked in terminal.
#For vivo, vitro
./update-versions.sh "${CURR}"
mvn -Dmessage="[maven-scm-plugin] prepare release vivo-${CURR}" scm:checkin -DpushChanges=false
mvn -Dtag="vivo-${CURR}" scm:tag -DpushChanges=false
./update-versions.sh "${NEXT}-SNAPSHOT"
mvn -Dmessage="[maven-scm-plugin] prepare development vivo-${NEXT}-SNAPSHOT" scm:checkin -DpushChanges=false |
Note | |||||||
---|---|---|---|---|---|---|---|
Your GPG passphrase may not be masked in terminal.
|
Inspect/Verify local updates:
Code Block |
---|
git diff HEAD~1
git diff HEAD~2 HEAD~1 |
These diffs should only contain changes of version numbers (from ${CURR}-SNAPSHOT to $CURR or $CURR to $NEXT) or occasionally HEAD to the current tag name ($REPO-$CURR)
Remove your local copies of VIVO artifacts to be sure of a clean build, and build the release.
Code Block |
---|
rm -rf ~/.m2/repository/org/vivoweb
git checkout $REPO-$CURR # detached head state
mvn clean install |
Warning |
---|
Up until this point, all of the changes made are strictly in your local repository and working directory. From this point on, the changes you make will be visible to the world and in some cases difficult to back-out of. |
Push the changes to Github.
Code Block |
---|
git push origin --tags # mvn task relies on the tag, make sure it does not collide with a branch name |
Go to
https://github.com/vivo-project/$REPO/releases/
- Click "Draft a new release", and update title to "Release $CURR"
- Attach appropriate artifacts
- Attach artifact MD5 files (e.g. artifact = jena2tools-1.2.0.jar, MD5 = jenatools-1.2.0.jar.md5)
If appropriate, attach binaries and checksums that have been published to Maven Central- Click Publish Release
Sonatype Release
Release the build artifacts to the Sonatype repository.
Code Block |
---|
mvn release:perform -DperformRelease -Dgoals=deploy |
Note | |||||||
---|---|---|---|---|---|---|---|
As before, your GPG passphrase may not be masked in terminal.
|
Warning | ||
---|---|---|
| ||
The following steps, once completed are final. They cannot be undone, revoked or altered. Only proceed if you've completed all the above steps and are absolutely certain the release is ready for publication. Additional Warning!! If autoReleaseAfterClose is set to true in your pom.xml then if the deploy passes the automated checks it WILL release! You will not be able to back this out! |
- Go to https://oss.sonatype.org/index.html (Nexus Repository Manager)
- Click on Log In (Top Right Corner) and use your ossrh id from your settings.xml file
Click Staging Repositories in left navigation under Build Promotion which will open a new tab
Search for "vivoweb" in upper right search box (project will not have $REPO in title)
- Select
Expand | ||
---|---|---|
| ||
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. |
Warning | ||
---|---|---|
| ||
The following steps, once completed are final. They cannot be undone, revoked or altered. Only proceed if you've completed all the above steps and are absolutely certain the release is ready for publication. |
- Go to https://oss.sonatype.org/index.html (Nexus Repository Manager)
- Click on Log In (Top Right Corner) and use your ossrh id from your settings.xml file
Click Staging Repositories in left navigation under Build Promotion which will open a new tab
Search for "vivoweb" in upper right search box (project will not have $REPO in title)
- Select repository and verify that $REPO is present in the Content tab
- Look for the correct types as well - war, pom, jar, md5, asc, etc.
- Note there is sometimes a delay on larger files showing in the Repo.
- Look for the correct types as well - war, pom, jar, md5, asc, etc.
- Click Close, then Refresh, then Release
- After a few moments click into the search under Artifact Search in the left navigation and type "vivoweb"
- A new Search tab will appear with all of the org.vivoweb Release artifacts
- Verify that the new release versions are now listed
- Note there is sometimes a delay on larger files showing in the Repo.
...
Push Release Branch to develop and Maintenance
The release branch has changes made since code freeze. It also contains the update to the version numbers for future development.
...
Ensure that your commit history matches the release branch's commit history, except for the two additional commits.
- 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.
...
Let Mike Conlon know that the release is complete and can be announced.
Helpful Tips - Debugging Issues
Key Issues?
Code Block |
---|
#Verify that your GPG key is in your ring
gpg --list-secret-keys
#If the key isn't listed import the private key your previously created
gpg --import name-of-private-key.asc
#List the keys again but in keyid LONG format
gpg --list-secret-keys --keyid-format LONG
#Take the keyid and setup git to use it as your global default.
git config --global user.signingkey YYYYXXXXYYYYXXXX
|
Oops Issues?
Code Block |
---|
#Need to delete a local RC branch with issues and start again?
git branch -D rel-${CURR}-RC
git fetch origin rel-${CURR}-RC
git checkout -b rel-${CURR}-RC --track origin/rel-${CURR}-RC
#Need to remove a tag locally and in GitHub?
git tag -d vivo-${CURR}
git push origin :refs/tags/vivo-${CURR}
|