Skip to content

RELEASING.md

Latest commit

 

History

History
68 lines (61 loc) · 5.19 KB

RELEASING.md

File metadata and controls

68 lines (61 loc) · 5.19 KB

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. Create an account at https://central.sonatype.org/register/legacy/. Do not use Github or other social logins. Add your Sonatype credentials to ~/.gradle/gradle.properties:
    • sonatypeOssUsername=«Jira@Sontype username»
    • sonatypeOssPassword=«Jira@Sontype password»

Releasing (PENDING CHANGES for ASF)

  1. Ensure that the revision you're about to promote has been successfully built on CI.
  2. Checkout the release branch for the version you're building (e.g. git checkout GEB_8_0_X)
  3. Update the version to the required one (usually just dropping -SNAPSHOT) in buildSrc/src/main/groovy/geb.coordinates.gradle file.
  4. Change {geb-version} expression used in History section in 140-project.adoc to a fixed version (the one that you're about to release).
  5. Commit with message "Version «number»" (don't push yet)
  6. Tag commit with name "v«number»" (still don't push yet)
  7. Run ./gradlew distSrc signDistSrc
  8. If you haven't already, checkout or update a local copy of the groovy-dev subversion repository from https://dist.apache.org/repos/dist/release/groovy-dev to a local directory of your choice.
    1. For example, svn checkout https://dist.apache.org/repos/dist/dev/groovy ~/groovy-dev to check it out for the first time.
    2. If you have already checked it out, cd into that directory and update it with svn update.
  9. Copy the artifacts from build/distributions to the appropriate subdirectory of your groovy-dev checkout (from the command above).
    1. For example: cp build/distributions/apache-groovy-geb* ~/groovy-dev/geb/${GEB_VERSION}
  10. Update the subversion repository with the appropriate subversion commands. For example:
    1. cd ~/work/groovy-dev
    2. svn add geb/${GEB_VERSION}
    3. svn commit --username yourusernamegoeshere@apache.org -m "New Geb version ${GEB_VERSION} added to staging area"
  11. git push the version branch and tag to GitHub
  12. read -s APACHE_PW and enter your password at the prompt
  13. Run ./gradlew --no-build-cache publishJarsAndManual -x :integration:geb-gradle:publishPlugins -PapacheUser=jonnybot -PapachePassword="${APACHE_PW}"
  14. Start the vote process on the groovy-dev mailing list. It will need at least 72 hours of remaining open and receive at least three affirmative votes from the Groovy PMC. See the Apache Voting process for more detail. Mention significant breaking changes if there are any.
  15. Assuming the vote passes (at least three +1 votes from the PMC), you can take the following steps to finalize the release.
  16. Email the vote thread to note that the vote has passed, with a final tally of the votes.
  17. Ask a member of the PMC to copy the artifacts from the staging directory in subversion to groovy-release/geb/${VERSION} and commit them to subversion, as above.
  18. Ask a member of the PMC to release the staging repository at https://repository.apache.org/#stagingRepositories
  19. Release the Gradle plugins with ./gradlew :integration:geb-gradle:publishPlugins

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. Merge the release branch back into the master branch.
  7. Bump Geb versions in example projects:
  8. 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.
  9. Wait for the build of the next version to pass and the site including manual for the released version to be published.
  10. Send an email to the mailing list announcing the release. You can use this one as a template.