I’m also a little confused. Volkan says he is creating the release tag during the CI release run. That won’t work as we should really avoid deleting tags created for releases. If the vote fails all that really should be done is to drop the artifacts from the Nexus staging repo. A new release build should replace the artifacts at dist.apache.org <http://dist.apache.org/> and create a new release tag. So when the release is approved the release manager should checkout the rc tag and tag it again as rel/n.n.n.
Ralph > On Feb 6, 2023, at 10:40 AM, Matt Sicker <m...@musigma.org> wrote: > > 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. >
