This is an automated email from the ASF dual-hosted git repository. meonkeys pushed a commit to branch develop in repository https://gitbox.apache.org/repos/asf/fineract.git
commit 30b25cdaa1a9faa348edfd2750c4ae43b9d5ecf2 Author: Adam Monsen <[email protected]> AuthorDate: Mon Dec 22 11:02:32 2025 -0800 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. --- fineract-doc/src/docs/en/chapters/release/process-step01.adoc | 2 ++ fineract-doc/src/docs/en/chapters/release/process-step08.adoc | 6 +++++- fineract-doc/src/docs/en/chapters/release/process-step09.adoc | 5 +++-- 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/fineract-doc/src/docs/en/chapters/release/process-step01.adoc b/fineract-doc/src/docs/en/chapters/release/process-step01.adoc index b847af602b..b1c935dd27 100644 --- a/fineract-doc/src/docs/en/chapters/release/process-step01.adoc +++ b/fineract-doc/src/docs/en/chapters/release/process-step01.adoc @@ -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. diff --git a/fineract-doc/src/docs/en/chapters/release/process-step08.adoc b/fineract-doc/src/docs/en/chapters/release/process-step08.adoc index e85db5a308..41cddef413 100644 --- a/fineract-doc/src/docs/en/chapters/release/process-step08.adoc +++ b/fineract-doc/src/docs/en/chapters/release/process-step08.adoc @@ -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+"] ---- diff --git a/fineract-doc/src/docs/en/chapters/release/process-step09.adoc b/fineract-doc/src/docs/en/chapters/release/process-step09.adoc index c0d177646f..bf06e40e51 100644 --- a/fineract-doc/src/docs/en/chapters/release/process-step09.adoc +++ b/fineract-doc/src/docs/en/chapters/release/process-step09.adoc @@ -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
