Okay, the mystery is solved. Matt has explained to me on Slack this documented-who-knows-where[1] feature about `rel/`-prefixed tags.
I have updated the CI script and the release documentation <https://github.com/apache/logging-log4j-tools/commit/06c7205b1c44439e120b39ff7db762ccb35aa69e>, created all necessary tags, and deleted old ones. [1] None of the following official release guides mention `rel/`-prefixed git tags: distribution <https://infra.apache.org/release-distribution>, creation <https://infra.apache.org/release-publishing.html>, and policy <https://www.apache.org/legal/release-policy.html>. On Fri, Feb 3, 2023 at 11:45 AM Volkan Yazıcı <vol...@yazi.ci> wrote: > 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. >
