Fineract release process improvement kickoff meeting.

Date

Goals

  • meet each other, share strengths & where we can help out
  • kick off Fineract release process improvement experiments

Agenda

  1. quick intros
  2. current process, in a nutshell
  3. learn about ATR
  4. brainstorm ideas

Attendees

Please include your name or pseudonym, role as it relates to Fineract, and, optionally, your coarse location on Earth.

Background

  • current Fineract release process
    • we're shipping one release per quarter
    • takes weeks from heads-up email to ship/announce
  • proposed Fineract release goals from last Fineract community meeting
    • stable, reliable, frequent, well-documented
    • avoid vendor lock-in, leverage open source, release from any platform
    • reproducible? non-goal, for now
  • recent release process improvement thread
    • Adam M. clarified current voting process (especially artifact verification)
      • verify release candidate checksum/signature, build source, run binary
    • Adam M. shared vision on what an improved process might look like
      • "one-click release"
  • ideas
    • make it easy (and just as robust) for the next release manager
    • make it easy (and just as robust) to be a confident release voter
  • Oct 20, 2025 press release: Apache Trusted Releases platform begins second Alpha

ATR presentation from Sean

  • Apache Trusted Releases alpha tool
  • 95% of current code written by Sean
  • 3-part process: 1. compose, 2. vote, 3. finish
  • aims to be easier and more secure
  • takes over distribution process
    • corresponds to Fineract release steps 8-12
    • ATR will provide lots of help w/step 9
  • provides some help w/verification
  • does all parts of voting
    • sends emails (has templates)
    • configurable (e.g. voting timeframe)
    • includes sending release announcements at the end
  • ATR step 1, compose: leverages github actions
    • secure uploads
  • PMC/voters will still need to download & verify release candidates
  • svn? no need to use it directly, ATR will abstract svn
  • finish: uploads release to other places
  • cli available, hits API
  • can use rsync to upload (instead of svn)
  • goal: full releases (steps 1-2-3 above, Fineract steps 8-12) by Jan 2026

Notes

  • current Fineract release process: are we doing it right?
    • it seems heavyweight
    • Sean: yes, seems like the right steps (and ATR can help improve it)
  • fineract binary tarball is approaching 500MiB. Any issues with that?
    • Sean: shouldn't be a problem
    • others have bigger artifacts, up to 1GiB
    • can still get special dispensation beyond that
  • any issues while using ATR: contact Sean, use mailing lists, use github
  • if/when we have reproducible builds: Apache security teams will support auto-uploading elsewhere from github
    • get release key, revocation cert
    • could simplify artifact verification stage
  • JIRA hygiene
    • it can be complicated, but it shouldn't be!
    • James: looking for further improvement/simplification here
    • Adam: I think it's better/easier lately, Adam S. did the JIRA clean-up step quickly for 1.13.0
    • devs/PMs are keeping things up to date always, so there's not a huge pile of work right at release time
  • goal ideas:
    • no svn by February
    • build/upload rc directly from gh actions by March
  • artifact verification simplification
    • Terence verifies releases w/a virtual machine, all scripted, all terminal-based
    • some projects provide scripts to verify releases, e.g. log4net
  • being secure should be a reward
    • more secure, reward is easier too
  • we need to improve post-release packaging (Debian, Docker)
    • tabled for now

Takeaways

  • lots of overlap with
    • Fineract release improvement ideas
    • what ATR provides / will provide
  • try it out: let's use ATR for next release
  • by Feb 2026: remove svn steps from Fineract release process
  • by Mar 2026: build rc directly on github, upload directly from there

Action items