Update release notes #294
Open
Update release notes #294
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There was a problem hiding this comment.
Pull Request Overview
This PR updates the release documentation to reflect the actual Apache Software Foundation (ASF) release process and fixes a repository URL reference in the README.
- Expanded and detailed the release process steps with Apache-specific procedures including subversion artifact management and PMC voting
- Added new post-release step to merge the release branch back into master
- Corrected GitHub repository URL from
geb/gebtoapache/groovy-geb
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| RELEASING.md | Detailed release and post-release steps with Apache-specific workflows including subversion management, voting process, and PMC responsibilities |
| README.md | Updated CONTRIBUTING.md link to use correct apache/groovy-geb repository path |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| 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. |
There was a problem hiding this comment.
The SVN URL mentions 'release' but should be 'dev' based on the example commands in the following lines that reference dist/dev/groovy.
Suggested change
| 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. | |
| 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/dev/groovy to a local directory of your choice. |
| 3. `svn commit --username [email protected] -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}"` |
There was a problem hiding this comment.
The hardcoded username 'jonnybot' should be replaced with a placeholder like yourusername to avoid confusion and indicate it should be customized.
Suggested change
| 13. Run `./gradlew --no-build-cache publishJarsAndManual -x :integration:geb-gradle:publishPlugins -PapacheUser=jonnybot -PapachePassword="${APACHE_PW}"` | |
| 13. Run `./gradlew --no-build-cache publishJarsAndManual -x :integration:geb-gradle:publishPlugins -PapacheUser=yourapacheusername -PapachePassword="${APACHE_PW}"` |
Comment on lines
+61
to
+68
| 6. Bump Geb versions in example projects: | ||
| * [geb-example-gradle](https://github.com/geb/geb-example-gradle) | ||
| * [geb-example-maven](https://github.com/geb/geb-example-maven) | ||
| 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 announcing the release. You can use [this one]() as a template. |
There was a problem hiding this comment.
Duplicate step numbering: both steps are numbered '6'. Step 61 should be numbered '7', and subsequent steps should be renumbered accordingly.
Suggested change
| 6. Bump Geb versions in example projects: | |
| * [geb-example-gradle](https://github.com/geb/geb-example-gradle) | |
| * [geb-example-maven](https://github.com/geb/geb-example-maven) | |
| 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 announcing the release. You can use [this one]() as a template. | |
| 7. Bump Geb versions in example projects: | |
| * [geb-example-gradle](https://github.com/geb/geb-example-gradle) | |
| * [geb-example-maven](https://github.com/geb/geb-example-maven) | |
| 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. |
| * 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 announcing the release. You can use [this one]() as a template. |
There was a problem hiding this comment.
The markdown link has an empty URL (). Either provide a valid URL to a template email or remove the link reference.
Suggested change
| 9. Send an email to the mailing list announcing the release. You can use [this one]() as a template. | |
| 9. Send an email to the mailing list announcing the release. You can use this one as a template. |
sdelamo
approved these changes
Nov 24, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These aren't quite perfect, but they're closer to the release reality now than they were before. It's also a decent checklist to weigh any future release automation against.