Hi James, Adam, > We should aim for AT LEAST quarterly, predictable releases No, I don't think that's the way to go. I understand that's the current situation, but we should aim AT LEAST monthly releases.
> So, right, what are the barriers? What improves the picture? What are the next incremental steps to focus on getting it right? Easy to grab artifacts for one. On top of the monthly releases, I'd still propose to take every single commit as a release candidate version of Fineract - since we have the very same testing, everything for a full release and for each commit, since everything is automated. We can mark those release candidate versions as they are not signed, didn't go through the whole full release process but other open source projects can easily publish snapshots. I don't see why we couldn't and shouldn't. Btw questionmark here, why can't we sign the snapshot releases? I'd ask back here, what's stopping us from doing this? What are the roadblocks? > Arnold, do we know for sure removing the legacy tags will affect many deployments and drive folks away from our (quarterly or better) official releases? I'm skeptical. Why aren't they speaking up? Well Adam, many Fineract customers are not speaking up, simply because they are not on the mailing list. In fact, if you think about it, if somebody forks Fineract (for good reason apparently), they just won't follow Fineract's lifeline anymore (at least not frequently). > Re: reproducibility -- yes, reproducibility is a Good Thing, but I disagree that legacy tags improve reproducibility. A sysadmin shouldn't rely on unofficial images always being available, and we shouldn't lead them to believe they would be. I assumed they were just a convenience for testing/demos/PRs. I was mostly reflecting on the fact that using "develop"/"latest" is not a good idea because it's not reproducible. On the other hand, a sysadmin should absolutely rely on images published on the apache/fineract dockerhub repo. Frankly speaking, unless you're heavy in regulation (i.e. a bank in the EU, or a lending SME of some sort), you just don't care whether an image is signed or not. Just as you start up a PostgreSQL container in Docker, I doubt you double-check whether that version is officially signed. On the other hand you are contradicting yourself (again, nothing personal here). If you assume it's just for testing/demos and things like that, imagine the situation where you prepare a demo with fineract:latest 3 days in advance and a restart makes it so latest now means the very last commit in Fineract which breaks your demo. Well, I'd say that's a pretty big issue when evaluating the viability of a solution. Not a good look. And again, back to reproducibility. And sorry for the delayed response, busy week for me. Best, Arnold Arnold Gálovics *CEO, Co-Founder* *+36 30 904 1885* https://docktape.com Docktape Technologies On Wed, Sep 17, 2025 at 9:05 PM Adam Monsen <[email protected]> wrote: > My reaction to Ádám's message starting this thread was +1, "whew, > finally!" because this is what I expect and hope to see from images on > Docker Hub: tags aligned with official releases, and a "latest" tag. > > Arnold, do we know for sure removing the legacy tags will affect many > deployments and drive folks away from our (quarterly or better) official > releases? I'm skeptical. Why aren't they speaking up? > > Agreed we should discuss big decisions, but I feel like this was done > properly and I'd generally prioritize continuous improvement and lazy > consensus above discussing/permission. > > Re: reproducibility -- yes, reproducibility is a Good Thing, but I > disagree that legacy tags improve reproducibility. A sysadmin shouldn't > rely on unofficial images always being available, and we shouldn't lead > them to believe they would be. I assumed they were just a convenience for > testing/demos/PRs. I considered using them, but it was easy to build my own > jars/wars/images so I didn't bother. > > Arnold, good point that sometimes a sysadmin needs a particular > feature/fix not part of an official release, and yes, we try to keep the > build passing on the develop branch, but do we guarantee any of this? > Should we? Are there other/better ways we could support sysadmins needing > to do this? For example, 1. a Docker image that builds Fineract > images/jars/wars reproducibly, 2. instructions on how to both leverage an > official release and include a feature/fix you need, 3. something we > already have/do (custom modules?) Just spitballing here, but surely we can > come up with some creative solutions. > > What if an unofficial build has a feature/fix a sysadmin *cannot* have, > and they also don't want exactly what's in an official release? They're > back to forking anyway. I think our best option with the resources we have > is continuing to improve the release process based on input from > deployments/community. > > James, +1 to your questions and ideas about the release process. I think > that's a good start. I can kick off the next release whenever we're ready > (using the current process -- and it should go faster than last time save > the necessary delays for voting and such). > > Recent release history, for posterity: > > *version* *release date* *resources* > 1.12.1 July 28, 2025 wiki > <https://cwiki.apache.org/confluence/display/FINERACT/1.12.1+-+Apache+Fineract>, > github <https://github.com/apache/fineract/releases/tag/1.12.1>, email > <https://lists.apache.org/thread/zd9z5prxt9qbv5xrkj2xy5s6o0nvzk7y> > 1.11.0 March 9, 2025 wiki > <https://cwiki.apache.org/confluence/display/FINERACT/1.11.0+-+Apache+Fineract>, > github <https://github.com/apache/fineract/releases/tag/1.11.0>, email > <https://lists.apache.org/thread/jn00ybtg148rqxno9sr1qdg0cqxktoht> > 1.10.1 December 30, 2024 wiki > <https://cwiki.apache.org/confluence/display/FINERACT/1.10.1+-+Apache+Fineract>, > github <https://github.com/apache/fineract/releases/tag/1.10.1>, email > <https://lists.apache.org/thread/1o4gtv54dhpv96kslgj3hhvpn8mp1stn> > > One more thought re: tags -- we might add, for example: "stable", "1", and > "1.12", etc. in addition to "1.12.1", if anyone wants/needs these. >
