Ok. Let’s make sure we have some sanity checks on this. It will need to be tested manually to gain some confidence with some set of seed data in the backend. Automated tests are preferred but for a first release I think we also need to be sure that the tests are catching basic features.
If that’s in place we should have either local tests or then move to create an infra ticket to host a test instance at Apache. We register the errors on github issues. Please provide that link. Can you help by describing “how to deploy” w seed data? Could a few community members offer to test? Sent from Gmail Mobile On Mon, Aug 17, 2026 at 1:26 PM Aman Mittal <[email protected]> wrote: > Hi James, > > Thank you for the +1 and for offering help with Infra and the release keys. > > Yes, I think the first release candidate should be validated against the > latest Fineract develop branch rather than being tied permanently to a > particular Fineract release version. > > For the first release, my proposal is: > > 1. The Fineract Backoffice UI release candidate is built and tested > against the latest stable state of Fineract's develop branch. > 2. The release candidate is cut from a specific Backoffice UI release > commit, so the UI release itself remains reproducible and immutable once > voted on. > 3. We document the exact Fineract commit/API specification against > which the release candidate was validated. This gives us a clear > compatibility baseline without requiring the UI release to be versioned in > lockstep with every Fineract release. > 4. We already have an automated API-spec synchronization workflow that > keeps the Backoffice UI aligned with the latest Fineract develop branch. PR > #381 is an example: > https://github.com/apache/fineract-backoffice-ui/pull/381 > > The automation resolves the latest Fineract state, updates the API > specification/client when the upstream specification changes, and opens a > PR for review rather than silently changing main. > > We have also previously had automated synchronization PRs for upstream API > changes/removals, including the MIX report removal: > > https://github.com/apache/fineract-backoffice-ui/pulls?q=is%3Apr+is%3Aclosed+label%3Aautomated > > That change was also discussed by the Fineract community in the dev list > thread regarding the deprecation and potential removal of the MIX XBRL > module (FINERACT-2670): > https://lists.apache.org/thread/mtp88gmrl5d3py5b7g3llo1d7lr023wv > > This is useful for the release model because it demonstrates that the > Backoffice UI can track API changes in Fineract develop through an > automated, reviewable process rather than assuming that the API remains > static. > > So I would suggest treating the first release as: > > Fineract Backoffice UI 1.0.0-RC.1 > | > +-- validated against Fineract develop at commit <specific commit> > +-- API contract recorded at that point > +-- release candidate tested against that backend > +-- compatibility baseline documented in the release notes > > After the first release, we can decide whether future UI releases should > be aligned with Fineract releases or follow an independent release cadence > with a documented compatibility matrix. > > Regarding a prerelease demo instance, I agree that this would be very > useful. ASF Infra supports publishing static sites through GitHub Pages: > > https://infra.apache.org/github-pages.html > > The Backoffice UI is already a static frontend, so a prerelease/demo build > could be published through GitHub Pages and linked from the release > candidate discussion. The main requirement is providing it with a reachable > Fineract backend/API; GitHub Pages itself can host the UI, but it cannot > provide the Fineract backend. > > This would allow the community to try the UI/UX before the formal release > vote and report issues against the release candidate. > > So, in short: yes, I propose that 1.0.0-RC.1 be validated against the > latest stable Fineract develop branch, with the exact backend/API commit > recorded as the compatibility baseline. A prerelease GitHub Pages demo > backed by a suitable Fineract instance would be a useful addition for > community validation. > > Regards, > Aman > > On Mon, Aug 17, 2026 at 4:01 PM James Dailey <[email protected]> > wrote: > >> +1 >> >> Thank you Aman. >> >> I’ll help as needed w karma on infra and keys >> >> TL;DR - Fineract headless backend will be getting a front end UI >> >> We need to decide release style - only in synch w latest release of >> Fineract? release commit for this first one only? >> >> As the first thing is a release candidate against latest fineract dev >> branch , as long as that is stable, ok to validate that. Yes? >> >> >> >> >> Sent from Gmail Mobile >> >> On Mon, Aug 17, 2026 at 11:08 AM sujan kumar <[email protected]> >> wrote: >> >>> Hi Aman, >>> >>> This looks like a solid and thorough release-readiness proposal. I know >>> how much effort and work has gone into getting the Backoffice UI to this >>> stage, and this is a really comprehensive overview of that progress. Great >>> to see the project reaching this level of release readiness. >>> >>> Looking forward to seeing the community and PMC feedback on the next >>> steps. >>> >>> Regards, >>> Sujan >>> >>> On Sun, 16 Aug, 2026, 22:07 Aman Mittal, <[email protected]> wrote: >>> >>>> Hello Fineract Community, >>>> >>>> I would like to propose that we start the process for the first >>>> official release of the Apache Fineract Backoffice UI. >>>> >>>> Tracking issue: >>>> https://github.com/apache/fineract-backoffice-ui/issues/377 >>>> >>>> The issue is intended to be the release-readiness and release-tracking >>>> umbrella for this work. It does not replace the formal ASF release vote. >>>> The release vote will be conducted on [email protected] in >>>> accordance with the ASF release policy. >>>> >>>> ASF Release Policy: >>>> https://www.apache.org/legal/release-policy.html >>>> <https://www.apache.org/legal/release-policy.html?utm_source=chatgpt.com> >>>> >>>> Fineract Release Documentation / Release Process: >>>> https://fineract.apache.org/docs/current/ >>>> <https://fineract.apache.org/docs/current/?utm_source=chatgpt.com> >>>> >>>> ASF Voting Process: >>>> https://www.apache.org/foundation/voting.html >>>> <https://www.apache.org/foundation/voting.html?utm_source=chatgpt.com> >>>> >>>> PROPOSAL >>>> >>>> I propose that Apache Fineract release the Fineract Backoffice UI as >>>> its first official release. >>>> >>>> The current audit indicates that the project is technically mature >>>> enough to proceed toward a release candidate, subject to resolving the >>>> remaining release-engineering items and receiving PMC guidance on the >>>> release scope, version, compatibility target, licensing questions, and >>>> Release Manager. >>>> >>>> My current proposal is to prepare a 1.0.0 release, initially through a >>>> 1.0.0-RC.1 candidate, rather than treating the current main branch as an >>>> informal release. >>>> >>>> WHY RELEASE NOW >>>> >>>> The Backoffice UI has reached a point where users and integrators can >>>> benefit from having a fixed, identifiable version rather than consuming an >>>> arbitrary state of main. >>>> >>>> A release would provide: >>>> >>>> - A versioned and reproducible source artifact. >>>> - A known Fineract API compatibility point. >>>> - A documented feature set. >>>> - An audited dependency and licensing state. >>>> - An SBOM for supply-chain review. >>>> - ASF-compliant LICENSE and NOTICE handling. >>>> - A documented testing and release process. >>>> - A fixed version against which users can report issues. >>>> - A clear statement of known limitations and Fineract >>>> compatibility. >>>> >>>> The release is also an opportunity to make the project's security, >>>> architecture, dependency, and functional state visible to the wider >>>> Fineract community rather than requiring users to inspect the repository >>>> themselves. >>>> >>>> CURRENT PROJECT STATUS >>>> >>>> A full release-readiness audit was performed against: >>>> >>>> 0846def1e7ce08cab809752f1808c2aa16b56f62 >>>> >>>> The audit covered: >>>> >>>> - Build and packaging >>>> - Unit tests >>>> - E2E tests >>>> - Real-backend E2E tests >>>> - RBAC >>>> - Navigation authorization >>>> - Action-level authorization >>>> - API surface >>>> - API contract synchronization >>>> - GA gates >>>> - Dependency licensing >>>> - Dependency vulnerabilities >>>> - Apache RAT >>>> - SBOM generation >>>> - CI/CD security >>>> - Accessibility >>>> - Functional coverage >>>> - Documentation >>>> - Deployment artifacts >>>> - Release hygiene >>>> >>>> CURRENT VERIFIED RESULTS >>>> >>>> Unit tests: >>>> 1093/1093 + 2/2 MFE project tests. >>>> >>>> E2E: >>>> 325 passed in the initial parallel execution. >>>> >>>> The 8 failures were investigated rather than simply ignored. They were >>>> reproduced successfully under the CI execution model: >>>> >>>> - backend: 12/12 passed >>>> - mocked accessibility: 3/3 passed >>>> >>>> The failures were attributed to host contention and test isolation >>>> under parallel execution. >>>> >>>> Two-factor authentication E2E: >>>> 3/3 passed against a dedicated real-backend stack. >>>> >>>> GA gates: >>>> 8/9 with 0 blocking failures. >>>> >>>> Build: >>>> PASS >>>> >>>> Lint: >>>> PASS >>>> >>>> Format: >>>> PASS >>>> >>>> i18n mechanism: >>>> PASS >>>> >>>> Internal endpoint validation: >>>> PASS >>>> >>>> Route permission drift check: >>>> PASS >>>> >>>> E2E typecheck: >>>> PASS >>>> >>>> Apache RAT: >>>> 706 approved, 0 unapproved. >>>> >>>> Production dependency licensing: >>>> 25/25 packages Category A after removal of eslint-plugin-sonarjs. >>>> >>>> Production dependency vulnerabilities: >>>> 0. >>>> >>>> RBAC: >>>> 223/223 declared permission codes validated against the platform >>>> catalogue. >>>> >>>> Navigation: >>>> 119 entries, 104 gated, with route/navigation permission parity >>>> enforced. >>>> >>>> Action authorization: >>>> 163 gating sites. >>>> 62 of 74 identified write controls are directly gated. >>>> The remaining 7 identified ungated controls all lead to routes that are >>>> themselves permission protected. >>>> >>>> API surface: >>>> 142 services / 564 operations. >>>> >>>> Committed API contract: >>>> 594 paths / 958 operations. >>>> >>>> The committed contract was verified against the Fineract head used by >>>> the audit with no operation-level additions or removals. >>>> >>>> Coverage: >>>> 73.72% statements excluding the generated OpenAPI client. >>>> Security-critical files are at least 90% covered. >>>> >>>> Functional inventory: >>>> 27 functional areas >>>> 333 routes >>>> 302 components >>>> 0 TODO/FIXME/HACK findings >>>> No dead routes identified. >>>> >>>> CURRENT FEATURES AND TECHNICAL ARCHITECTURE >>>> >>>> The Backoffice UI is an Angular-based application intended to provide >>>> an operational interface over Apache Fineract. >>>> >>>> The architecture currently includes the following major capabilities: >>>> >>>> 1. Angular application architecture >>>> >>>> The application uses modern Angular application patterns with >>>> standalone components and feature-oriented route organization. >>>> >>>> The application is divided into functional areas rather than treating >>>> the UI as one monolithic feature. >>>> >>>> Examples include: >>>> >>>> - Clients >>>> - Groups >>>> - Centers >>>> - Loans >>>> - Savings >>>> - Shares >>>> - Accounting >>>> - Products >>>> - Tellers >>>> - Reports >>>> - System/configuration >>>> - Users and roles >>>> - Notifications >>>> - Search >>>> - Profile and dashboard functionality >>>> >>>> >>>> 2. API integration >>>> >>>> The UI uses the Fineract REST API as its backend contract. >>>> >>>> The generated API client and committed API specification are kept >>>> synchronized with Fineract. >>>> >>>> The project maintains an API-surface manifest containing the operations >>>> actually used by the UI. >>>> >>>> This provides two independent controls: >>>> >>>> - API contract compatibility >>>> - Actual API usage tracking >>>> >>>> The API surface currently covers: >>>> >>>> 142 services >>>> 564 operations >>>> >>>> 3. Permission and RBAC model >>>> >>>> The application uses the Fineract permission vocabulary rather than >>>> defining an independent authorization model. >>>> >>>> The existing AuthService provides: >>>> >>>> - Individual permission checks >>>> - OR semantics >>>> - AND semantics >>>> - ALL_FUNCTIONS >>>> - ALL_FUNCTIONS_READ >>>> - Permission normalization >>>> >>>> Route-level authorization has now been implemented using a permission >>>> guard. >>>> >>>> Navigation permissions and route permissions are checked for drift in >>>> CI. >>>> >>>> The UI also uses action-level permission directives for privileged >>>> operations. >>>> >>>> The important architectural decision is that the frontend RBAC is >>>> defence-in-depth. >>>> >>>> Fineract Core remains the authoritative security boundary. >>>> >>>> The UI does not attempt to replace backend authorization. >>>> >>>> 4. Navigation authorization >>>> >>>> Navigation is data-driven through NAV_CONFIG. >>>> >>>> Permission-protected navigation entries are filtered according to the >>>> user's permissions. >>>> >>>> The project also has a static validation mechanism ensuring that >>>> navigation permissions and route permissions do not silently diverge. >>>> >>>> This prevents a situation where a menu hides a feature but its route >>>> remains unrestricted, or where the navigation exposes something that the >>>> route subsequently refuses. >>>> >>>> 5. Route-level authorization >>>> >>>> Protected routes now explicitly declare their required Fineract >>>> permission. >>>> >>>> For example, a read-only screen can require a READ_* permission while >>>> creation and modification screens require CREATE_* or UPDATE_* permissions. >>>> >>>> This allows ALL_FUNCTIONS_READ users to access read functionality while >>>> preventing them from reaching write forms. >>>> >>>> Unauthorized navigation results in a dedicated Access Denied page >>>> rather than silently returning the user to the dashboard. >>>> >>>> 6. Action-level authorization >>>> >>>> Privileged operations such as: >>>> >>>> - Create >>>> - Update >>>> - Delete >>>> - Approve >>>> - Reject >>>> - Disburse >>>> - Repayment >>>> - Waive >>>> - Configuration >>>> - User management >>>> - Role management >>>> - Permission management >>>> - Teller operations >>>> - Accounting operations >>>> - Reports >>>> >>>> are permission-gated where applicable. >>>> >>>> The existing permission directive is used instead of introducing a >>>> second authorization abstraction. >>>> >>>> 7. Two-factor authentication >>>> >>>> The application includes two-factor authentication functionality and >>>> has dedicated E2E coverage against a real backend. >>>> >>>> The release audit includes a real-backend test path rather than relying >>>> exclusively on mocked authentication. >>>> >>>> 8. Configuration-driven deployment >>>> >>>> Runtime configuration is provided separately from the application build. >>>> >>>> This allows deployments to configure items such as: >>>> >>>> - Fineract API URL >>>> - Tenant >>>> - RBAC enablement >>>> - Institution features >>>> - Developer tooling >>>> - Navigation overrides >>>> - API-origin restrictions >>>> >>>> >>>> 9. Security controls >>>> >>>> The project currently includes security-oriented CI checks covering >>>> areas such as: >>>> >>>> - CSP >>>> - API-origin restrictions >>>> - Authorization header handling >>>> - Sanitization/raw HTML checks >>>> - GitHub Actions pinning >>>> - Workflow permissions >>>> - Dependency scanning >>>> - License policy >>>> - RAT >>>> - Signed commits >>>> >>>> >>>> 10. API contract synchronization >>>> >>>> The project has automation for keeping the API contract synchronized >>>> with Fineract. >>>> >>>> The current design resolves the Fineract container/image to a digest, >>>> checks the API specification, regenerates the client when the contract >>>> changes, and opens a PR. >>>> >>>> The backend E2E suite also exercises the UI against Fineract. >>>> >>>> This is intended to reduce API drift between the UI and Fineract Core. >>>> >>>> 11. Testing architecture >>>> >>>> Testing currently consists of: >>>> >>>> - Angular unit tests >>>> - MFE tests >>>> - Mocked Playwright E2E tests >>>> - Real-backend Playwright E2E tests >>>> - Two-factor E2E tests >>>> - Accessibility checks >>>> - API-surface validation >>>> - Route permission drift checks >>>> - i18n checks >>>> - Build validation >>>> - GA checks >>>> - Dependency checks >>>> - RAT >>>> >>>> >>>> 12. SBOM and supply-chain transparency >>>> >>>> The project generates CycloneDX 1.6 SBOMs. >>>> >>>> The release audit generated: >>>> >>>> - Production SBOM >>>> - Full dependency-tree SBOM >>>> >>>> The SBOMs will be regenerated from the final release candidate so that >>>> the PMC can review the exact release contents rather than relying on an >>>> SBOM generated from an earlier commit. >>>> >>>> The current generator does not provide component hashes, and this >>>> limitation is documented rather than fabricating hash information. >>>> >>>> RELEASE ENGINEERING ITEMS REMAINING >>>> >>>> The main remaining work is release engineering rather than a large >>>> feature implementation. >>>> >>>> 1. Versioning >>>> >>>> The repository currently reports 0.0.0. >>>> >>>> The release version needs to be agreed by the PMC/community and then >>>> applied consistently to package metadata, generated federation metadata, >>>> SBOM metadata and release artifacts. >>>> >>>> My initial proposal is: >>>> >>>> 1.0.0-RC.1 >>>> >>>> followed by: >>>> >>>> 1.0.0 >>>> >>>> assuming the RC passes review and the release vote. >>>> >>>> 2. Release documentation >>>> >>>> The project needs release documentation covering: >>>> >>>> - Release preparation >>>> - Release candidate creation >>>> - Signing >>>> - Checksums >>>> - SBOM generation >>>> - RAT verification >>>> - Candidate verification >>>> - Staging >>>> - Voting >>>> - Promotion >>>> - Announcement >>>> >>>> I propose adding RELEASING.md and CHANGELOG.md as part of the release >>>> preparation. >>>> >>>> 3. Release Manager >>>> >>>> I am willing to nominate myself as Release Manager for the first >>>> Backoffice UI release. >>>> >>>> I have already performed the release-readiness audit and have been >>>> working through the release blockers, so I can continue the mechanical >>>> preparation and verification work. >>>> >>>> However, because this is the first official release of this project, I >>>> would specifically like PMC guidance and approval before proceeding as >>>> Release Manager. >>>> >>>> If the PMC is comfortable with me acting as RM, I am prepared to: >>>> >>>> - Prepare the release branch/tag. >>>> - Prepare the RC artifacts. >>>> - Generate and verify the SBOM. >>>> - Run RAT over the actual release artifact. >>>> - Generate checksums. >>>> - Sign the release artifacts. >>>> - Stage the release candidate. >>>> - Prepare the release vote email. >>>> - Monitor the vote. >>>> - Prepare the vote result. >>>> - Promote the artifacts after a successful vote. >>>> - Prepare the release announcement. >>>> >>>> I would appreciate guidance from the PMC on whether I should proceed in >>>> this role and whether there are any Fineract-specific release steps beyond >>>> the documented process that I should follow. >>>> >>>> 4. Container release scope >>>> >>>> The current container image builds successfully, but the audit >>>> identified a deployment issue: >>>> >>>> The current nginx configuration does not proxy /api/ requests to >>>> Fineract. >>>> >>>> As a result, an API request can fall through to the SPA shell. >>>> >>>> The compose configuration also currently points at a third-party public >>>> demo host by default. >>>> >>>> Additionally, the Dockerfile currently uses npm install rather than npm >>>> ci. >>>> >>>> Therefore, I propose that the PMC/community explicitly decide whether >>>> the first official release is: >>>> >>>> A. Source release only >>>> >>>> or >>>> >>>> B. Source release plus a convenience container image. >>>> >>>> If the container is part of the official release scope, the identified >>>> deployment issues should be fixed and tested before the vote. >>>> >>>> The ASF release policy states that official releases are source >>>> materials, while convenience binaries/bytecode packages may be distributed >>>> alongside the source release when they meet the applicable requirements. >>>> >>>> Reference: >>>> >>>> https://www.apache.org/legal/release-policy.html >>>> <https://www.apache.org/legal/release-policy.html?utm_source=chatgpt.com> >>>> >>>> 5. Fineract compatibility >>>> >>>> The current release-readiness audit validates the UI against Fineract >>>> head / 1.16.0-SNAPSHOT. >>>> >>>> The current evidence does not establish complete compatibility with >>>> Fineract 1.15. >>>> >>>> Therefore, I would like PMC/community guidance on whether the first >>>> Backoffice UI release should target: >>>> >>>> - Fineract 1.16.x / current head >>>> - Fineract 1.15.x >>>> - A documented compatibility range >>>> >>>> If 1.15 compatibility is required, I propose adding an API >>>> compatibility check and a real-backend E2E matrix against a pinned Fineract >>>> 1.15 image before the release vote. >>>> >>>> DEPENDENCY AND ASF LICENSING REVIEW >>>> >>>> The dependency audit was performed against the full dependency tree as >>>> well as production dependencies. >>>> >>>> The previous direct devDependency: >>>> >>>> eslint-plugin-sonarjs >>>> >>>> was licensed under LGPL-3.0-only. >>>> >>>> It has been removed and replaced with permissively licensed >>>> alternatives under: >>>> >>>> https://github.com/apache/fineract-backoffice-ui/pull/378 >>>> >>>> The current audit reports: >>>> >>>> Category A: >>>> 1188 dependencies/components >>>> >>>> Acknowledged BlueOak-1.0.0: >>>> 7 >>>> >>>> Category B: >>>> 2, test-only >>>> >>>> Category X: >>>> 0 >>>> >>>> Unclassified: >>>> 0 >>>> >>>> Production dependencies: >>>> 25 packages, all Category A. >>>> >>>> The project also added a licensing gate so future dependency changes >>>> are classified as: >>>> >>>> Category A: PASS >>>> Category B: REVIEW >>>> Category X: BLOCK >>>> Unknown: BLOCK >>>> >>>> There is, however, one licensing question I would like the >>>> community/PMC to be aware of: >>>> >>>> Blue Oak Model License 1.0.0 is not currently included in the ASF >>>> Category A list used by our automated policy. >>>> >>>> There is an existing ASF Legal JIRA issue: >>>> >>>> LEGAL-639: >>>> https://issues.apache.org/jira/browse/LEGAL-639 >>>> <https://issues.apache.org/jira/browse/LEGAL-639?utm_source=chatgpt.com> >>>> >>>> That issue specifically discusses whether Blue Oak Model License 1.0.0 >>>> is acceptable for ASF Category A. >>>> >>>> The license is currently acknowledged by the project's dependency audit >>>> rather than silently treated as ordinary Category A. >>>> >>>> I would appreciate confirmation from the PMC/legal process on whether >>>> this treatment is appropriate for Fineract, or whether the project should >>>> take any additional action. >>>> >>>> The dependency itself is currently only present through build tooling >>>> and is not part of the production dependency tree. >>>> >>>> SBOM >>>> >>>> For the release candidate, I propose that we regenerate the SBOM from >>>> the exact release candidate source tree. >>>> >>>> The release package will therefore have an auditable dependency >>>> inventory corresponding to the actual release candidate rather than an >>>> earlier working-tree audit. >>>> >>>> The current audit generated CycloneDX 1.6 SBOMs for: >>>> >>>> - Production dependencies >>>> - Full dependency tree >>>> >>>> The existing SBOM limitation is that the current generator does not >>>> provide component hashes. This will be documented explicitly rather than >>>> presenting incomplete data as if it were complete. >>>> >>>> The final release candidate SBOM will be regenerated and >>>> attached/staged with the release evidence for PMC review. >>>> >>>> FUNCTIONAL READINESS >>>> >>>> The functional audit currently identifies: >>>> >>>> 27 functional areas >>>> 333 routes >>>> 302 components >>>> >>>> No TODO/FIXME/HACK markers were identified in the functional inventory. >>>> >>>> The project currently provides functionality around the major >>>> Backoffice operational areas, including: >>>> >>>> - Dashboard >>>> - Clients >>>> - Groups >>>> - Centers >>>> - Loans >>>> - Savings >>>> - Shares >>>> - Products >>>> - Accounting >>>> - Tellers >>>> - Reports >>>> - System/configuration >>>> - Users >>>> - Roles >>>> - Permissions >>>> - Notifications >>>> - Search >>>> - Profile >>>> - Authentication >>>> - Two-factor authentication >>>> >>>> The release audit also specifically verified the relationship between: >>>> >>>> - UI navigation >>>> - Route authorization >>>> - Action authorization >>>> - Fineract backend authorization >>>> >>>> The goal is not to claim that every Fineract capability is perfectly >>>> represented in the UI. Instead, the release documentation should provide an >>>> explicit functional inventory and identify unsupported or known-limited >>>> areas. >>>> >>>> KNOWN FUNCTIONAL LIMITATIONS >>>> >>>> The current audit identified three functionality limitations caused by >>>> verified Fineract PostgreSQL defects rather than UI implementation gaps. >>>> >>>> GLIM: >>>> >>>> Creation fails with: >>>> >>>> null value in column "principal_amount" of relation "glim_accounts" >>>> violates not-null constraint >>>> >>>> GSIM: >>>> >>>> The request is accepted and returns gsimId: 0, but no parent record is >>>> created. >>>> >>>> Centre collection sheet: >>>> >>>> command=generateCollectionSheet returns HTTP 500 due to: >>>> >>>> operator does not exist: boolean = integer >>>> >>>> These are tracked in: >>>> >>>> https://github.com/apache/fineract-backoffice-ui/issues/376 >>>> >>>> They should be documented as known release limitations unless the >>>> corresponding Fineract defects are resolved before the release. >>>> >>>> OTHER KNOWN LIMITATIONS >>>> >>>> Hindi and Korean translations are currently approximately 20.9% >>>> complete. >>>> >>>> Untranslated strings fall back to English. >>>> >>>> One WCAG 2.1 AA contrast issue was identified in the current theme: >>>> >>>> #3498db background >>>> #ffffff foreground >>>> 3.15:1 contrast ratio >>>> >>>> No WCAG compliance claim is being made for the release. >>>> >>>> The RBAC route protection is defence-in-depth. Fineract Core remains >>>> the authoritative security boundary. >>>> >>>> RELEASE ARTIFACT AND VERIFICATION PROPOSAL >>>> >>>> For the release candidate I propose that we produce: >>>> >>>> - Source distribution >>>> - Detached ASCII-armored signature >>>> - SHA-512 checksum >>>> - Production SBOM >>>> - Full dependency SBOM >>>> - Dependency license report >>>> - RAT report >>>> - Release verification instructions >>>> - Changelog >>>> - Release notes >>>> >>>> The candidate should be tested independently from the working tree. >>>> >>>> RAT should be executed against the actual source distribution, not >>>> merely against the Git checkout. >>>> >>>> The ASF release policy requires supplied packages to be >>>> cryptographically signed and requires LICENSE and NOTICE to correctly >>>> account for the contents of the package. >>>> >>>> Reference: >>>> >>>> https://www.apache.org/legal/release-policy.html >>>> <https://www.apache.org/legal/release-policy.html?utm_source=chatgpt.com> >>>> >>>> PROPOSED RELEASE PROCESS >>>> >>>> Subject to PMC guidance, I propose the following sequence: >>>> >>>> 1. Resolve the remaining release blockers. >>>> 2. Agree on: >>>> - release version >>>> - supported Fineract version >>>> - source-only vs source + container scope >>>> - Release Manager >>>> 3. Add/finalize release documentation. >>>> 4. Update version metadata. >>>> 5. Regenerate the SBOM from the final RC source tree. >>>> 6. Perform the final dependency and ASF licensing audit. >>>> 7. Build the release candidate from a clean checkout. >>>> 8. Run RAT against the release source archive. >>>> 9. Verify LICENSE and NOTICE. >>>> 10. Generate SHA-512 checksums. >>>> 11. Sign the source archive. >>>> 12. Verify the signature independently. >>>> 13. Stage the RC according to the applicable ASF/Fineract release >>>> process. >>>> 14. Send the [VOTE] thread to [email protected]. >>>> 15. Keep the vote open for at least 72 hours under the normal ASF >>>> release policy. >>>> 16. Collect the required binding votes. >>>> 17. If approved, publish/promote the release according to ASF >>>> policy. >>>> 18. Publish the release announcement. >>>> 19. Tag the final release and update the project documentation. >>>> >>>> The ASF policy requires at least three binding +1 votes and more >>>> positive than negative binding votes for a release, with release votes >>>> normally remaining open for at least 72 hours. >>>> >>>> Reference: >>>> >>>> https://www.apache.org/legal/release-policy.html >>>> <https://www.apache.org/legal/release-policy.html?utm_source=chatgpt.com> >>>> >>>> Fineract's existing release documentation: >>>> >>>> https://fineract.apache.org/docs/current/ >>>> <https://fineract.apache.org/docs/current/?utm_source=chatgpt.com> >>>> >>>> ASF voting process: >>>> >>>> https://www.apache.org/foundation/voting.html >>>> <https://www.apache.org/foundation/voting.html?utm_source=chatgpt.com> >>>> >>>> REQUEST FOR PMC / COMMUNITY GUIDANCE >>>> >>>> Before I proceed with the remaining release engineering work, I would >>>> appreciate guidance on the following: >>>> >>>> 1. Is the community/PMC supportive of proceeding toward the first >>>> official Fineract Backoffice UI release? >>>> 2. Is 1.0.0 an appropriate version for the first official release, >>>> with 1.0.0-RC.1 as the first release candidate? >>>> 3. Which Fineract version should the release officially target? >>>> 4. Should the first release be source-only, or should a container >>>> image be included? >>>> 5. Should the current Blue Oak Model License dependency treatment >>>> be considered acceptable, given LEGAL-639? >>>> 6. Is the PMC comfortable with me acting as Release Manager for >>>> this first release? >>>> 7. Are there any additional Fineract-specific release requirements >>>> that I should incorporate before creating the RC? >>>> 8. Are there any concerns with the current functional scope or >>>> known limitations that should prevent an RC from being prepared? >>>> >>>> RELEASE MANAGER NOMINATION >>>> >>>> I would like to explicitly volunteer to act as Release Manager for this >>>> first release. >>>> >>>> I am willing to take responsibility for the release preparation and >>>> execution, including the audit, candidate preparation, artifact signing, >>>> staging, vote coordination, verification and final publication. >>>> >>>> Since this would be the first official release of the Backoffice UI, I >>>> would prefer to proceed only after receiving explicit guidance/approval >>>> from the PMC on the mailing list. >>>> >>>> If the PMC is comfortable with me taking the RM role, I can proceed >>>> with the remaining release work on a self-serve basis and keep the >>>> community updated through the release tracking issue and dev@ mailing >>>> list. >>>> >>>> TRACKING >>>> >>>> GitHub release tracking issue: >>>> >>>> https://github.com/apache/fineract-backoffice-ui/issues/377 >>>> >>>> Known Fineract functionality issues: >>>> >>>> https://github.com/apache/fineract-backoffice-ui/issues/376 >>>> >>>> Dependency licensing change: >>>> >>>> https://github.com/apache/fineract-backoffice-ui/pull/378 >>>> >>>> ASF Legal JIRA — Blue Oak Model License: >>>> >>>> https://issues.apache.org/jira/browse/LEGAL-639 >>>> <https://issues.apache.org/jira/browse/LEGAL-639?utm_source=chatgpt.com> >>>> >>>> ASF Release Policy: >>>> >>>> https://www.apache.org/legal/release-policy.html >>>> <https://www.apache.org/legal/release-policy.html?utm_source=chatgpt.com> >>>> >>>> ASF Voting Process: >>>> >>>> https://www.apache.org/foundation/voting.html >>>> <https://www.apache.org/foundation/voting.html?utm_source=chatgpt.com> >>>> >>>> Fineract Release Process: >>>> >>>> https://fineract.apache.org/docs/current/ >>>> <https://fineract.apache.org/docs/current/?utm_source=chatgpt.com> >>>> >>>> SUMMARY >>>> >>>> In summary, I believe the Backoffice UI is ready to begin the formal >>>> release-preparation process, with the remaining work primarily around >>>> release engineering, documentation, artifact scope, compatibility >>>> confirmation and PMC decisions. >>>> >>>> I am not proposing that we vote on the release in this email. >>>> >>>> I am proposing that we agree on the release direction first, resolve >>>> the remaining release blockers, and then prepare a reproducible 1.0.0-RC.1 >>>> candidate for formal review and vote. >>>> >>>> I am also volunteering to serve as Release Manager, subject to PMC >>>> guidance and approval. >>>> >>>> Feedback, concerns, additional release requirements, and guidance on >>>> the proposed version, compatibility target and release scope would be very >>>> welcome. >>>> >>>> Regards, >>>> >>>> Aman Mittal >>>> Apache Fineract Contributor/Committer >>>> >>>>
