Gary, let me address your questions here to avoid polluting the voting thread. See my comments inline below.
> A minor note: The tags don't look to me like they are named properly. > In other projects, I see and do, for example: > > someartifact-1.0.2-rc1 is the tag for an RC > rel/someartifact-1.0.2 is the tag for the release where infra makes > rel/ tags read-only, at least I'm pretty sure they do. > > Having a tag for an RC gives us better traceability IMO. A release candidate is a semantical label we give to releases that are not yet _closed_ (aka. promoted) in `repository.apache.org`. It is only meaningful in the context of a voting process. I have tried to explain this in log4j-changelog README <https://github.com/apache/logging-log4j-tools/blob/master/log4j-changelog/README.adoc#i-am-about-to-deploy-a-new-log4j-release-what-shall-i-do> : "Log4j _releases_ and _release candidates_ all get deployed to the same _staging repository_. Their `pom.xml` files all contain the same release version, e.g., `2.19.0`. There are no `-rc1`, `-rc2`, etc. suffixes in the version of a release candidate. Once a release candidate voting reaches a consensus for release, associated artifacts simply get promoted from the staging to the public repository. Hence, there are [technically] no differences between releases and release candidates." Therefore, to simplify the cognitive load and implementation, I have no mention of RC anywhere for log4j-tools releases. Once CI succeeds deploying artifacts to Nexus, both the artifacts and the git tag are set. When PMC signals the green light, the release manager simply closes/promotes the artifacts in `repository.apache.org`. Since commit IDs are available in the voting email, we don't lose any traceability. I am confused with your "... is the tag for the release where infra makes" statement. What is _infra_ in this context? log4j-tools has no such _infra_. > Another minor note: Doubling SHA checksums seems over-the-top in > https://dist.apache.org/repos/dist/dev/logging/log4j/ I'd stick to > 512. Implemented in 486a4151f8c3c11a477930f61d9e1de5a7bad741. > it blows up with: > ... > Unrecognized option: --add-exports You should have received a `maven-enforcer-plugin` failure telling that you are using Java 8, but the build requires Java 11. Due to 11-specific entries in `.mvn/jvm.config` (a mistake from my side), you couldn't even run Maven, hence the blow up. I have fixed this and added a "Build" section to the README in 47012783f9835473729f0695cabebb335f0f5afb > I ... hate it when downloads try to take over my tooling. > If I unzip the zip file and run what I run every day: 'mvn' A build system should impose as minimum requirements from the host machine as possible. That is why build tools like Gradle, Maven, Bazel, etc. provide _wrappers_. This way the only requirement on the host system becomes a JDK and nothing else. This also makes sure everybody (incl. CI!) uses the very same build tool – a reproducibility win. Long story short, providing and using wrappers is a best-practice.
