37 lines
1.6 KiB
Plaintext
37 lines
1.6 KiB
Plaintext
= Release Process (Jenkins)
|
|
|
|
Details for releasing ORM via a Jenkins job.
|
|
|
|
The release can alternatively be performed manually - see <<./manual-release-process.adoc>> for details.
|
|
|
|
== Resources
|
|
|
|
First, a list of resources you will need access to in order to perform a release:
|
|
|
|
* Post permissions for both hibernate-dev and hibernate-announce mailing lists
|
|
* Post permissions for Hibernate forums
|
|
* Post permissions for both G+ and Twitter
|
|
|
|
|
|
== Steps
|
|
|
|
1. Perform `./gradlew preVerifyRelease` locally (after pulling all upstream changes). The Jenkins job does only the release steps, and we need to make sure tests and checkstyle especially are ok
|
|
2. Mark the version as released in Jira
|
|
3. Close all issues associated with the version as closed. Be sure to remove the version from any issues that are not resolved (e.g. rejected) - the Jira "release notes" mechanism includes all issues with that version as the fix-for regardless of the resolution
|
|
4. Start the https://ci.hibernate.org/view/Release/job/hibernate-orm-release-jdk17/[Jenkins job]. It is a parameterized build - Jenkins will prompt user for needed information:
|
|
.. The version to be released (e.g. 7.0.0.Final)
|
|
.. The next development version (e.g. 7.0.1-SNAPSHOT)
|
|
.. The GitHub branch from which to release
|
|
|
|
The Jenkins job performs the following tasks:
|
|
|
|
1. sets the version to the provided release version
|
|
2. updates the changelog with the info from Jira
|
|
3. performs bintray, sourceforge and documentation upload
|
|
4. tags the version and push it to github
|
|
5. changes the version to the provided development version
|
|
6. push to github
|
|
|
|
== Post-release steps
|
|
|
|
See <<./post-release-steps.adoc>> |