He may be referring to the infra-enforced tag naming scheme where any tags prefixed with “rel/“ are immutable and cannot be deleted. If you start with a tag like `foo-1.2-rc1` and it passes a release vote, then you’d make an alias tag on that tag named `rel/1.2`.
> On Feb 3, 2023, at 4: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.
