[We had a video call with Ralph. There I addressed his points. I will share them here one more time for the record.]
1. We need to upload the generated emails somewhere, hence they are there. Otherwise they are not a part of the distribution. I could have uploaded them as artifacts attached to the GitHub Actions run. I have used this in the past for `logging-log4j-tools` and the experience (i.e., downloading them, unpacking them again, etc.) was more cumbersome compared to using SVN (`svn update` and done). 2. We agreed to move the distribution BeanShell to a Maven plugin residing in `log4j-tools` in the future and stick to the current simple setup for now. 3. I will set the version to `10.0.0`. This indeed warrants an RC2. 4. I will also automate the steps 1-3 in `RELEASING.adoc`. 5. The CI job triggered by a commit to a `release/`-prefixed branch is idempotent and will perform all necessary artifact+distribution staging for every run. Hence, one can perfect the release by simply keep on pushing to `release/x.y.z`. On Tue, Sep 5, 2023 at 8:31 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > 1. I don’t understand why there is are email-announce and email-vote text > files in the distribution directory. The release notes should be in the > distribution itself. > 2. As expected I very much dislike the bean shell script in the parent > pom. > 3. As Matt pointed out, the version number is smaller than the previous > version. Since the parent project is just a pom.xml semantic versioning > doesn’t really make much sense here. But having a version smaller than the > previous version is just not OK. > > I am -1 on this release due to item 3. I’d be -0.5 otherwise. > > Question - reading the RELEASING doc is there a reason steps 1-3 can’t be > performed by a GitHub action? > > Where I work we use Jenkins pipelines. We have a “release-create” goal > that creates the release branch ready to go. The release branch then shows > up in Jenkins as something that can be built via a pipeline (along with dev > and master). We then select the release branch and do “build now” to > generate a release. When that is completed we run the “release-merge” > job. Something like this with GitHub Actions seems more reasonable than > the manual steps one still has to do. > > Ralph > > > > On Sep 4, 2023, at 12:33 PM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > > > This is a vote to release the Apache Logging Parent 1.10.0. > > > > Source repository: https://github.com/apache/logging-parent > > Commit: 3dd83461faa058690a5ed821ee81dfc2d744ec7c > > Distribution: https://dist.apache.org/repos/dist/dev/logging > > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1113 > > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > > > Please download, test, and cast your votes on this mailing list. > > > > [ ] +1, release the artifacts > > [ ] -1, don't release, because... > > > > This vote is open for 72 hours and will pass unless getting a > > net negative vote count. All votes are welcome and we encourage > > everyone to test the release, but only the Logging Services PMC > > votes are officially counted. At least 3 +1 votes and more > > positive than negative votes are required. > > > > # Release Notes > > > > This minor release contains various improvements that we expect to > > relieve the load on `pom.xml` and GitHub Actions workflows of > > Maven-based projects we parent. This is of particular importance while > > managing and cutting releases from multiple repositories. > > See `README.adoc` for the complete list of features and their usage. > > > > See [this `logging-log4j-tools` GitHub Actions workflow > > run]( > https://github.com/apache/logging-log4j-tools/actions/runs/6070379396) > > demonstrating a successful release cut using a SNAPSHOT version of > > this `logging-parent` release. All preparations (release notes, > > distribution ZIP, vote & announcement emails, etc.) are staged to both > > Nexus and SVN and waiting the release manager to proceed. As a matter > > of fact, this very release of `logging-parent` is cut by the very same > > reusables too. > > > > ## Changes > > > > ### Added > > > > * Added `changelog-export` profile to easily export changelogs to > Markdown files > > * Added `changelog-release` profile to easily move > > `src/changelog/.?.x.x` contents to their associated release directory > > * Added `deploy` profile to ease the Maven `deploy` goal > > * Added `distribution` profile to easily create a distribution file > > containing Git-tracked sources, release notes, binary attachments, > > `NOTICE.txt`, etc. > > * Documented release instructions (i.e., `RELEASING.md`) > > * Added `release` profile to share common release-specific Maven > configuration > > * Added reusable GitHub Actions workflows to share CI boilerplate for > > other repositories > > * Switched to using `log4j-changelog-maven-plugin` for managing > > changelog and release notes > >
