👍 On Tue, Dec 16, 2025 at 1:28 PM James Dailey <[email protected]> wrote:
> +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"). >> >> -- -- Paul
