+1 Kick it off
On Tue, Dec 16, 2025 at 9:47 AM Adam Monsen <[email protected]> wrote: > 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"). > >
