...
Using the above variables, complete the below git commands for each module being released. The modules to be released are shown in the Fedora modules release plan. A new page may need to be added for this release. When the steps below are complete for a specific module, change the color to green, so that others know what's been done.
NOTE: The value of RC_VERSION will vary for each release.
...
| Code Block |
|---|
mvn versions:set -DnewVersion=${RC_VERSION}-SNAPSHOT |
Verify that the previous SNAPSHOT version is no longer anywhere in the code base. Verify that the code base builds.
Tag the release candidate branch
...
These build scripts may be of use for building the set of release candidate modules.
Once a release has been created, it should be uploaded to GitHub as a Pre-Release. A Pre-Release should be created for fcrepo4, fcrepo-webapp-plus, and fcrepo4-vagrant. The name should be "Release Candidate 1 - RC_VERSION"
Notes
The vagrant release cannot be tested until after the fcrepo-webapps-plus RC files have been uploaded to GitHub, as the vagrant file relies on them being there first.
Update online resources
If any online resources have been modified or added to during the release, these must be updated.
...
Push Release Branch to 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.
...