FWIW, the rel/ prefix is mentioned here: https://commons.apache.org/releases/release.html as well as on the pages of some other Apache projects.
But not that you could have guessed to look there ;-) This was announced quite a while back on the infra ML IIRC but now I could not find it. Gary On Mon, Feb 6, 2023, 16:45 Volkan Yazıcı <vol...@yazi.ci> wrote: > 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. > > >
