Copilot commented on code in PR #294: URL: https://github.com/apache/groovy-geb/pull/294#discussion_r2538372994
########## RELEASING.md: ########## @@ -26,24 +26,43 @@ limitations under the License. # Releasing (PENDING CHANGES for ASF) 1. Ensure that the revision you're about to promote has been successfully built on [CI](https://github.com/apache/groovy-geb/actions). -1. Update the version to the required one (usually just dropping -SNAPSHOT) in `buildSrc/src/main/groovy/geb.coordinates.gradle` file. -1. Change `{geb-version}` expression used in `History` section in `140-project.adoc` to a fixed version (the one that you're about to release). -1. Commit with message "Version «number»" (don't push yet) -1. Tag commit with name "v«number»" (still don't push yet) -1. Run `./gradlew publishJarsAndManual closeAndReleaseStagingRepositories` -1. Wait for the new version to [appear in Maven Central](http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.gebish%22%20AND%20a%3A%22geb-core%22), this might take several hours. +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. Review Comment: The SVN URL mentions 'release' but should be 'dev' based on the example commands in the following lines that reference `dist/dev/groovy`. ```suggestion 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. ``` ########## RELEASING.md: ########## @@ -26,24 +26,43 @@ limitations under the License. # Releasing (PENDING CHANGES for ASF) 1. Ensure that the revision you're about to promote has been successfully built on [CI](https://github.com/apache/groovy-geb/actions). -1. Update the version to the required one (usually just dropping -SNAPSHOT) in `buildSrc/src/main/groovy/geb.coordinates.gradle` file. -1. Change `{geb-version}` expression used in `History` section in `140-project.adoc` to a fixed version (the one that you're about to release). -1. Commit with message "Version «number»" (don't push yet) -1. Tag commit with name "v«number»" (still don't push yet) -1. Run `./gradlew publishJarsAndManual closeAndReleaseStagingRepositories` -1. Wait for the new version to [appear in Maven Central](http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.gebish%22%20AND%20a%3A%22geb-core%22), this might take several hours. +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 [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}"` Review Comment: The hardcoded username 'jonnybot' should be replaced with a placeholder like `yourusername` to avoid confusion and indicate it should be customized. ```suggestion 13. Run `./gradlew --no-build-cache publishJarsAndManual -x :integration:geb-gradle:publishPlugins -PapacheUser=yourapacheusername -PapachePassword="${APACHE_PW}"` ``` ########## RELEASING.md: ########## @@ -26,24 +26,43 @@ limitations under the License. # Releasing (PENDING CHANGES for ASF) 1. Ensure that the revision you're about to promote has been successfully built on [CI](https://github.com/apache/groovy-geb/actions). -1. Update the version to the required one (usually just dropping -SNAPSHOT) in `buildSrc/src/main/groovy/geb.coordinates.gradle` file. -1. Change `{geb-version}` expression used in `History` section in `140-project.adoc` to a fixed version (the one that you're about to release). -1. Commit with message "Version «number»" (don't push yet) -1. Tag commit with name "v«number»" (still don't push yet) -1. Run `./gradlew publishJarsAndManual closeAndReleaseStagingRepositories` -1. Wait for the new version to [appear in Maven Central](http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.gebish%22%20AND%20a%3A%22geb-core%22), this might take several hours. +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 [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}"` +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](https://www.apache.org/foundation/voting.html) 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. -1. Remove the oldest version from `manuals.include()` call in `site.gradle` and append the newly released one. -1. Add a placeholder above the newest version in `History` section in `140-project.adoc` using `{geb-version}` expression. -1. Commit with message 'Begin version «version»' -1. Push (make sure you push the tag as well). -1. 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) -1. 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. -1. Wait for the build of the next version to pass and the site including manual for the released version to be published. -1. Send an email to the mailing list, you can use [this one](https://web.archive.org/web/20220822074356/https://groups.google.com/g/geb-user/c/VmqpY4Z6JrY) as a template. Please mention significant breaking changes if there are any. +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. +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. Review Comment: The markdown link has an empty URL `()`. Either provide a valid URL to a template email or remove the link reference. ```suggestion 9. Send an email to the mailing list announcing the release. You can use this one as a template. ``` ########## RELEASING.md: ########## @@ -26,24 +26,43 @@ limitations under the License. # Releasing (PENDING CHANGES for ASF) 1. Ensure that the revision you're about to promote has been successfully built on [CI](https://github.com/apache/groovy-geb/actions). -1. Update the version to the required one (usually just dropping -SNAPSHOT) in `buildSrc/src/main/groovy/geb.coordinates.gradle` file. -1. Change `{geb-version}` expression used in `History` section in `140-project.adoc` to a fixed version (the one that you're about to release). -1. Commit with message "Version «number»" (don't push yet) -1. Tag commit with name "v«number»" (still don't push yet) -1. Run `./gradlew publishJarsAndManual closeAndReleaseStagingRepositories` -1. Wait for the new version to [appear in Maven Central](http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.gebish%22%20AND%20a%3A%22geb-core%22), this might take several hours. +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 [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}"` +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](https://www.apache.org/foundation/voting.html) 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. -1. Remove the oldest version from `manuals.include()` call in `site.gradle` and append the newly released one. -1. Add a placeholder above the newest version in `History` section in `140-project.adoc` using `{geb-version}` expression. -1. Commit with message 'Begin version «version»' -1. Push (make sure you push the tag as well). -1. 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) -1. 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. -1. Wait for the build of the next version to pass and the site including manual for the released version to be published. -1. Send an email to the mailing list, you can use [this one](https://web.archive.org/web/20220822074356/https://groups.google.com/g/geb-user/c/VmqpY4Z6JrY) as a template. Please mention significant breaking changes if there are any. +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. +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. Review Comment: Duplicate step numbering: both steps are numbered '6'. Step 61 should be numbered '7', and subsequent steps should be renumbered accordingly. ```suggestion 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. ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
