docs: adapt artifact checks to new ATR tool

We're already reaping rewards for using ATR (checks+voting+email support), and I want us to do both the old way AND the new way for now. I'll consider the old release process in "soft deprecation" as the ATR matures.
2025-12-22 11:02:32 -08:00
parent f4aa11468d
commit 30b25cdaa1
3 changed files with 10 additions and 3 deletions
@@ -4,6 +4,8 @@

 The RM should, if one doesn't already exist, first create a new release umbrella issue in JIRA. This issue is dedicated to tracking (a summary of) any discussion related to the planned new release. An example of such an issue is https://issues.apache.org/jira/browse/FINERACT-873[FINERACT-873].

+Next, the RM logs in to https://release-test.apache.org[the ATR (ASF Trusted Releases)] tool and clicks "+ Start a new release", naming the release `{revnumber}`.
+
 The RM then creates a list of resolved issues & features through an initial check in JIRA for already resolved issues for the release, and then setup a timeline for release branch point. The time for the day the issue list is created to the release branch point must be at least two weeks in order to give the community a chance to prioritize and commit any last minute features and issues they would like to see in the upcoming release.

 The RM must then send the pointer to the umbrella issue along with the tentative timeline for branch point to the developer lists. Any work identified as release related that needs to be completed should be added as a sub tasks of the umbrella issue to allow all developers and users to see the overall release progress in one place. The umbrella issue shall also link to any issues still requiring clarification whether or not they will make it into the release.
@@ -11,7 +11,11 @@ Next we'll stage the release candidate. Create a new folder and add these files:
 * apache-fineract-src-{revnumber}.tar.gz.sha512
 * apache-fineract-src-{revnumber}.tar.gz.asc

-These files (or "artifacts") comprise the release candidate. Upload these files to https://www.apache.org/legal/release-policy.html#stage[ASF's distribution dev/staging area] like so:
+These files (or "artifacts") comprise the release candidate.
+
+First, upload these files to https://release-test.apache.org/compose/fineract/{revnumber}. This tool will initiate automated checks on the files. We'll come back to those in next step and ensure they pass.
+
+Next, upload these files to https://www.apache.org/legal/release-policy.html#stage[ASF's distribution dev/staging area] like so:

 [source,bash,subs="attributes+"]
 ----
@@ -2,9 +2,9 @@

 == Description

-Following are the typical things we need to verify before voting on a release candidate. And the release manager should verify them too before calling out a vote.
+Following are the typical things we need to verify before voting on a release candidate. And the release manager should verify them too before calling out a vote. Some of these checks are duplicated by https://release-test.apache.org[the ATR (ASF Trusted Releases) tool], and will need to continue to be duplicated until we get more comfortable with that tool.

-Make sure release artifacts are hosted at https://dist.apache.org/repos/dist/dev/fineract
+Make sure release artifacts are hosted at both https://release-test.apache.org/compose/fineract/{revnumber} AND https://dist.apache.org/repos/dist/dev/fineract

 * Release candidate files should match filenames mentioned earlier, and will be moved without renaming if/when the release vote passes.
 * Verify signatures and hashes. You may have to import the public key of the release manager to verify the signatures. (`gpg --import KEYS` or `gpg --recv-key <key id>`)
@@ -14,6 +14,7 @@ Make sure release artifacts are hosted at https://dist.apache.org/repos/dist/dev
 * All files have correct headers (Rat check should be clean - `./gradlew rat`)
 * No jar files in the source artifacts
 * All tests pass both in CI and locally
+* All ATR checks pass

 === Artifact verification