...
- Which platform/configuration combinations will be tested
- Which automated tests will be run, and by whom
- Which manual tests will be run, and by whom
- Which service compatibility tests (external search, external triplestore) will be run, and by whom
- Instructions on how testers will report on test results
Create release
...
branches and begin final test phase
Create a release candidate branch and a development branch, release testing wiki page and notify developers to test.
| Code Block | ||
|---|---|---|
| ||
RC_VERSION=4.5.1 |
...
NOTE: The value of RC_VERSION will vary for each release.
Release candidate branches CANNOT have the same version property as the master branch in the pom.xml file. The versions on the master branch will need to be incremented at the same time you create the release branches. You will need to pull in another community member to create a pull request with the version change, or another committer if you are going to create the pull requests yourself.
| Code Block |
|---|
git checkout master
git pull
git push origin master:${RC_VERSION}-RC
git push origin master:DEV |
Tag the release candidate branch
| Code Block |
|---|
git tag -a "<artifact-id>-${RC_VERSION}-RC-1" -m "<artifact-id>-${RC_VERSION}-RC-1"
git push origin --tags |
Then we must merge the pull requests to increment the version numbers to the master branch.
Example: During the 4.5.1 release our branches should have the version 4.5.1-SNAPSHOT, this will be incremented on the master branch to 4.5.2-SNAPSHOT
Update online resources
If any online resources have been modified or added to during the release, these must be updated.
...
| Expand | |||||||||
|---|---|---|---|---|---|---|---|---|---|
|
Push Release Branch to Master
...
|
...
| Code Block |
|---|
git checkout ${CURR}-RC # this is your local copy of the release branch
git log |
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
| Info |
|---|
fcrepo-vagrant is an exception to the above rule. The master branch of fcrepo4-exts/fcrepo-vagrant is tied to the last full release version. So you don't update the Fedora version to the new SNAPSHOT version but instead leave it at the just released (${CURR}) version. |
If this appears correct, you can push your release branch on to master.
| Code Block |
|---|
git push origin HEAD:master |
| Info |
|---|
Because there are no changes to master after code freeze and all bug fixes are on the ${CURR}-RC branch, this will operate as a fast-forward merge. |
Merge DEV branch into master
...
Complete the Duraspace wiki documentation updates
Current, in-progress Fedora Repository Documentation wiki: https://wiki.duraspace.org/display/FEDORA4x
...