Hey y'all, let's talk about the 1.14.0 release!
I volunteer to be release manager.
Our last release was completed on Oct 20
<https://lists.apache.org/thread/f1ymthf5mt81tzyjbmn11yth956c02n1>, so
if we stick with quarterly releases we should do the Q4 release now-ish.
I'm looking at dee325ec
<https://github.com/apache/fineract/commit/dee325ec7f26e559c839e59bd5efdafda2d24801>
as a likely branch point since CI is green for that commit. I brought it
up in chat
<https://mifos.slack.com/archives/C028634A61L/p1765902189794649> and
haven't heard any dealbreakers yet. Please speak up asap here or in chat
if there's any reason to delay the release. Stability is key
<https://lists.apache.org/thread/sq9x7qg04s3fj5ycqrs7z3sqxm7tp434>.
I'll follow process in the existing docs
<https://fineract.apache.org/docs/current/#_releases> (updating as I go,
as usual) and use the Fineract Release Plugin, and I'm also going to
pilot the ATR (Apache Trusted Releases) platform
<https://tooling.apache.org/trusted-releases.html> we've been discussing
lately
<https://lists.apache.org/thread/f99mhvxg9l3wz17thmwonvgn6vyz05vq>. I've
been learning about ATR, trying it out, and chatting with the
maintainers. I'm excited it will make our release process both simpler,
more efficient, and more robust.
I'll start today and hopefully we can finish the ceremony before my
holidays kick off, but it's also OK if it needs to bleed over into the
new year.
On 10/17/25 08:59, Adam Monsen wrote:
Thank you Terence! Everything helps. I'll take you up on that offer of
assistance and I appreciate it greatly. I'll look for places we can
team up.
re: components ... I think it was Aleks who coached me into thinking
of the codebase as a monolith, even with the optimistic separation of
the code into modules. The logic is not evenly distributed, it's
mostly useful as one big chunk (with the exception of fineract-client,
perhaps?). At any rate, the modules roll up into a single gradle
project with multiple gradle sub-projects and building everything is
not really any harder than building an individual module. As far as
module maintenance goes: I don't know, I've done very little of that
lately. But in an IDE we're basically just working on the whole
monolith at once, right?
In terms of improving/simplifying the code as a way to improve
everything (including releases), the fundamental action that would
probably be the most helpful and also the hardest is culling cruft we
don't need or use (starting with defining "we" and "need").
