Provide guidelines and templates for the release process

[swebb2066]

Having never done a release, I need to document it so at least I known what to do.

[ppkarwasz]

Could you also document how to review the release during the vote?

• What should we call to compile and test the release? We can use a Docker image to verify reproducibility.
• How can we verify that the code has not been corrupted à-la-XZ?

[swebb2066]

Yes, I am planning that. Robert, I recall you provided some review instructions for the last release. Could you add them into this PR?

The email template currently expects them to be in https://github.com/apache/logging-log4cxx/admin/release-review-instructions.md

[rm5248]

Are these the review instructions you're talking about? https://lists.apache.org/thread/4vr3k0jfdn8rtl2ck1p0gw9y2gj6tckv

[rm5248]

These two steps here(Download the latest release artifacts and Sign release artifacts) should be automatically handled for you if you do -DAPACHE_MAINTAINER=ON; I know you changed something about that recently and I haven't gone back and checked to make sure that it still works.

[ppkarwasz]

INFRA-26194 added secrets to our runners, so we can do those things automatically, i.e.:

1. Sign the archives on the Github runner.
2. Commit everything to the dev subversion repository.

I can try updating the workflows tomorrow.

[swebb2066]

Commit everything to the dev subversion repository.

What will we use to trigger this? I do not believe we should to do it on every commit.

[ppkarwasz]

Hi Stephen,

Commit everything to the dev subversion repository.

What will we use to trigger this? I do not believe we should to do it on every commit.

In Log4j we have two different workflows:

• On each commit to the default branch a snapshot is published to the Nexus Repository, but no source code. The binaries are not signed. I believe that the Log4cxx equivalent would be to just attach the source distribution to the GHA run.
• The deploy-release workflow is triggered by each push to branches named release/<version>. This workflow signs the artifacts (both binary and source) and uploads them to the subversion repository.