Skip to content

Latest commit

 

History

History
34 lines (30 loc) · 2.87 KB

RELEASING.md

File metadata and controls

34 lines (30 loc) · 2.87 KB
Raw

Required accounts and credentials

  1. Generate a GPG key pair and distribute the public key as per this blog post. Add the following entries to ~/.gradle/gradle.properties:
    • signing.keyId=«key id»
    • signing.password=«key password»
    • signing.secretKeyRingFile=«path to the secure gpg keyring (not public)»
  2. Sign up for a Jira account @ Sonatype. Send your Jira username to someone who is already allowed to publish Geb to Sonatype so that they add a comment this ticket to request access rights for you. Add your Sonatype credentials to ~/.gradle/gradle.properties:
    • sonatypeOssUsername=«Jira@Sontype username»
    • sonatypeOssPassword=«Jira@Sontype password»

Releasing

  1. Ensure that the revision you're about to promote has been successfully built on CI.
  2. Update the version to the required one (usually just dropping -SNAPSHOT) in buildSrc/src/main/groovy/geb.coordinates.gradle file.
  3. Change {geb-version} expression used in History section in 140-project.adoc to a fixed version (the one that you're about to release).
  4. Commit with message "Version «number»" (don't push yet)
  5. Tag commit with name "v«number»" (still don't push yet)
  6. Run ./gradlew publishJarsAndManual closeAndReleaseStagingRepository
  7. Wait for the new version to appear in Maven Central, this might take several hours.

Post-release actions

  1. Bump the version to a snapshot of the next planned version.
  2. Remove the oldest version from manuals.include() call in site.gradle and append the newly released one.
  3. Add a placeholder above the newest version in History section in 140-project.adoc using {geb-version} expression.
  4. Commit with message 'Begin version «version»'
  5. Push (make sure you push the tag as well).
  6. Bump Geb versions in example projects:
  7. Update issues and milestones in Github tracker:
    • Find all unresolved issues in the tracker that have the fix version set to the recently released version and bulk edit them to have the fix version set to the next version.
    • Find the recently released milestone, change the version number if it's different from the one that was released and close it.
  8. Wait for the build of the next version to pass and the site including manual for the released version to be published.
  9. Send an email to the mailing list, you can use this one as a template. Please mention significant breaking changes if there are any.