Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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
  • being secure should be a reward
    • more secure, reward is easier too
  • thoughts about 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