40 lines
2.2 KiB
Plaintext
40 lines
2.2 KiB
Plaintext
= Release Process (manual)
|
|
|
|
Details for releasing ORM manually from developers machine.
|
|
|
|
The release can alternatively be performed via a Jenkins job - see <<./jenkins-release-process.adoc>> for details
|
|
|
|
|
|
== Resources
|
|
|
|
First, a list of resources you will need access to in order to perform a release:
|
|
|
|
* JBoss doc server - SSH key. See List of resources a dev team member needs access to
|
|
* SourceForge - SSH key. There is a great wiki on SourceForge covering setting up your SSH key ( https://sourceforge.net/p/forge/documentation/SSH/ ). You must also be added to the admin group of the Hibernate SourceForge project.
|
|
* Bintray - Uses an "api key". Both the username (PERSONAL_BINTRAY_USER) and the api key (PERSONAL_BINTRAY_API_KEY) are needed - add them to ~/.gradle/gradle.properties. To find your api key, go to Bintray.com > Edit Profile > API Key.
|
|
* Post permissions for both hibernate-dev and hibernate-announce mailing lists. Again, see List of resources a dev team member needs access to
|
|
* Post permissions for Hibernate forums
|
|
* Post permissions for both G+ and Twitter
|
|
|
|
NOTE: Realistically, release builds can only be run on *Nix systems. We rely on system commands for parts of the release tasks in the build script. Specifically we use `rsync` and `ln` (for symlink creation).
|
|
|
|
== Steps
|
|
|
|
Many release steps have been automated, but some still need to be done manually:
|
|
|
|
1. Mark version released in Jira
|
|
2. Bulk close all the version's Jira tickets
|
|
3. Get changelog from Jira and add to `../changelog.txt`
|
|
4. Change version in `gradle/version.properties` to the release version
|
|
5. Commit - do not push, because pushing will cause CI to upload another staging repository
|
|
6. Do the release - from the root-dir, `./gradlew release`. This relies on Gradle's UP-TO-DATE checks, assuming you have verified the build already. `./gradlew cleanAndRelease` can be used instead to trigger a full clean+build for the release
|
|
7. Verify / trigger the sync to Central from BinTray happened. This never seems to happen automatically so plan on triggering the sync manually.
|
|
8. Create the release tag
|
|
9. Change version in `gradle/version.properties` to the next development version
|
|
10. Commit
|
|
11. Push (both the branch and tag) upstream
|
|
|
|
|
|
== Post-release steps
|
|
|
|
See <<./post-release-steps.adoc>> |